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SECTION  1.  INTRODUCTION  TO  VOLUME  3 

Volume  Three  of  the  1985  DDN  Protocol  Handbook,  a  three-volume  set,  contains 
implementation  f^uidelines  and  several  auxiliary  documents  of  use  to  protocol 
implementors  in  both  the  DoD  and  DARPA  internet  communities.  Volumes  One  and 
Two  contain  the  actual  protocols  as  well  as  details  about  DoD  and  ARPANET  Protocol 
review  and  acceptance  policies.  Volume  Three  should  be  used  in  conjunction  with 
either  or  both  of  the  other  two  volumes. 

The  price  for  the  three-volume  set  is  $110.00,  prepaid,  to  cover  the  cost  of  reproduction 
and  handling.  Checks  should  be  made  payable  to  SRI  International.  Copies  of  the 
handbook  will  also  be  deposited  at  DTIC. 

Additional  copies  of  the  1085  DDN  Protocol  Handbook  can  be  ordered  from: 

DDN  Network  Information  Center 
SRI  International,  Room  EJ291 
333  Ravenswood  Avenue 
Menlo  Park,  CA  94025 
Telephone:  (800)  235-3155 
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RFC:  813 


WINDOW  AND  ACKNOWLEDGEMENT  STRATEGY  IN  TCP 


David  D.  Clark 

MIT  Laboratory  for  Cooputar  Science 
Cooputer  SysteDs  and  Coonunicationa  Group 
July,  1982 


1 .  Introduction 

This  document  describes  inplenentation  strategies  to  deal  with  two 
mechanisms  in  TCP,  the  window  and  the  acknowledgement.  These  mechanisms 
are  described  in  the  specification  document,  but  it  is  possible,  while 
complying  with  the  specification,  to  produce  inplenentations  which  yield 
very  bad  performance.  Hippily,  the  pitfalls  possible  in  window  and 
acknowledgement  strategies  are  very  easy  to  avoid. 

It  is  a  much  more  difficult  exercise  to  verify  the  performance  of  a 
specification  than  the  correctness.  Certainly,  we  have  less  experience 
in  this  area,  and  we  certainly  lack  any  useful  formal  technique. 
Nonetheless,  it  is  important  to  atteopt  a  specification  in  this  area, 
because  different  implmaentors  ai^ht  otherwise  choose  superficially 
reasonable  algorithms  which  interact  poorly  with  each  other.  This 
document  presisnts  a  particular  set  of  algorithms  which  have  received 
testing  in  the  field,  and  which  appear  to  work  properly  with  each  other. 
With  more  experience,  these  algorithms  may  become  part  of  the  formal 
specification:  until  such  time  their  use  is  recommended. 
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2.  The  Mechanisms 

The  acknowledgement  mechanism  is  at  the  heart  of  TCP.  Very  sinply, 
when  data  arrives  at  the  recipient,  the  protocol  requires  that  it  send 
back  an  acknowledgement  of  this  data.  The  protocol  specifies  that  the 
bytes  of  data  are  sequentially  numbered,  so  that  the  recipient  can 
acknowledge  data  by  naming  the  hipest  numbered  byte  of  data  it  has 
received,  which  also  acknowledges  the  previous  bytes  (actually,  it 
identifies  the  first  byte  of  data  which  it  has  not  yet  received,  but 
this  is  a  small  detail) .  The  protocol  contains  only  a  general  assertion 
that  data  should  be  acknowledged  promptly,  but  gives  no  more  specific 
indication  as  to  how  quickly  an  acknowledgement  must  be  sent,  or  how 
much  data  should  be  acknowledged  in  each  separate  acknowledgenent . 

The  window  mechanism  is  a  flow  control  tool.  Whenever  appropriate, 
the  recipient  of  data  returns  to  the  sender  a  number,  which  is  (more  or 
less)  the  size  of  the  buffer  which  the  receiver  currently  has  available 
for  additional  data.  This  number  of  bytes,  called  the  window,  is  the 
maximum  which  the  sender  is  permitted  to  transmit  until  the  receiver 
returns  some  additional  window.  Sometimes,  the  receiver  will  have  no 
buffer  space  available,  and  will  return  a  window  value  of  zero.  Under 
these  circumstances, the  protocol  req^jires  the  sender  to  send  a  small 
segment  to  the  receiver  now  then,  to  see  if  more  data  is  acc^ted. 
If  the  window  remains  closed  at  zero  for  some  substantial  period,  and 
the  sender  can  obtain  no  response  from  the  receiver,  the  protocol 
requires  the  sender  to  conclude  that  the  receiver  has  failed,  and  to 
close  the  connection.  Again,  there  is  very  little  performance 
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information  in  the  specification,  describing  under  what  circumstances 
the  window  should  be  increased,  and  how  the  sender  should  respond  to 
such  revised  infonnation. 

A  bad  implementation  of  the  window  algorithm  can  lead  to  extremely 
poor  performance  overall.  The  degradations  which  occur  in  throughput 
and  CPU  utilizations  can  easily  be  several  factors  of  ten,  not  just  a 
fractional  increase.  This  particular  phenomenon  is  specific  enou^^  that 
it  has  been  given  the  name  of  Silly  Window  Syndrome,  or  SWS.  Happily 
SWS  is  easy  to  avoid  if  a  few  simple  rules  are  observed.  The  most 
important  function  of  this  memo  is  to  describe  SWS,  so  that  implementors 
will  understand  the  general  nature  of  the  problem,  and  to  describe 
algorithms  which  will  prevent  its  occurrence.  This  document  also 
describes  performance  enhancing  algorithms  which  relate  to 
acknowledgement,  and  discusses  the  way  acknowledgement  and  window 
algorithms  interact  as  part  of  SWS. 

3.  SILLY  WINDOW  SYNDROME 

In  order  to  understand  SWS,  we  must  first  define  two  new  terms. 
Superficially,  the  window  mechanism  is  very  sinple:  there  is  a  number, 
called  "the  window",  which  is  returned  from  the  receiver  to  the  sender. 
However,  we  must  have  a  more  detailed  way  of  talking  about  the  meaning 
of  this  number.  The  receiver  of  data  computes  a  value  which  we  will 
call  the  "offered  window".  In  a  sinple  case,  the  offered  window 
corresponds  to  the  amount  of  buffer  space  available  in  the  receiver. 
This  correspondence  is  not  necessarily  exact,  but  is  a  suitable  model 
for  the  discussion  to  follow.  It  is  the  offered  window  which  is 
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actually  transmitted  back  from  the  receiver  to  the  sender.  The  sender 
uses  the  offered  window  to  conpute  a  different  value,  the  "usable 
window",  which  is  the  offered  window  minus  the  amount  of  outstanding 
unacknowledged  data.  The  usable  window  is  less  than  or  equal  to  the 
offered  window,  and  can  be  much  smaller. 

Consider  the  following  simple  exanple.  The  receiver  initially 
provides  an  offered  window  of  1,000.  The  sender  uses  vjp  this  window  by 
sending  five  segments  of  200  bytes  each.  The  receiver,  on  processing 
the  first  of  these  segments,  returns  an  acknowledgement  which  also 
contains  an  \jpdated  window  value.  Let  us  assume  that  the  receiver  of 
the  data  has  removed  the  first  200  bytes  from  the  buffer,  so  that  the 
receiver  once  again  has  1,000  bytes  of  available  buffer.  Therefore,  the 
receiver  would  return,  as  before,  an  offered  window  of  1,000  bytes.  The 
sender,  on  receipt  of  this  first  acknowledgement,  now  conputes  the 
additional  number  of  bytes  which  may  be  sent.  In  fact,  of  the  1,000 
bytes  which  the  recipient  is  prepared  to  receive  at  this  time,  800  are 
already  in  transit,  having  been  sent  in  resporise  to  the  previous  offered 
window.  In  this  case,  the  usable  window  1*  only  200  bytes. 

Let  us  now  consider  how  SWS  arises.  To  continue  the  previous 
exanple,  assume  tliat  at  some  point,  when  the  sender  conputes  a  useable 
window  of  200  bytes,  it  has  only  50  bytes  to  send  until  it  reaches  a 
"push"  point.  It  thus  sends  50  bytes  in  one  segment,  and  150  bytes  in 
the  next  segment.  Sometime  later,  this  50-byte  segment  will  arrive  at 
the  recipient,  which  will  process  and  remove  the  50  bytes  and  once  again 
return  an  offered  window  of  1,000  bytes.  However,  tlie  sender  will  now 
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conpute  that  there  are  950  bytes  in  transit  in  the  network,  so  that  the 
useable  window  is  now  only  50  bytes.  Thus,  the  sender  will  once  again 
send  a  50  byte  segment,  even  though  there  is  no  longer  a  natural 
boundary  to  force  it. 

In  fact,  whenever  the  acknowledgement  of  a  small  segment  comes 
back,  the  useable  window  associated  with  that  acknowledgement  will  cause 
another  segment  of  the  same  small  size  to  be  sent,  until  some 
abnormality  breaks  the  pattern.  It  is  easy  to  see  how  small  segments 
arise,  because  natural  boundaries  in  the  data  occasionally  cause  the 
sender  to  take  a  confuted  useable  window  and  divide  it  \sp  between  two 
segments.  Once  that  division  has  occurred,  there  is  no  natural  way  for 
those  useable  window  allocations  to  be  recombined;  thus  the  breaking  up 
of  the  useable  window  into  small  pieces  will  persist. 

Ihus,  SWS  is  a  degeneration  in  the  throug^ut  which  develops  over 
time,  during  a  long  data  transfer.  If  the  sender  ever  stops,  as  for 
example  when  it  runs  out  of  data  to  send,  the  receiver  will  eventually 
acknowledge  all  the  outstanding  data,  so  that  the  useable  window 
conputed  by  the  sender  will  equal  the  full  offered  window  of  the 
receiver.  At  this  point  the  situation  will  have  healed,  and  further 
data  transmission  over  the  link  will  occur  efficiently.  However,  in 
large  file  transfers,  which  occur  without  interruption,  SWS  can  cause 
appalling  pjerformance.  The  network  between  the  sender  and  the  receiver 
becomes  clogged  with  many  small  segments,  and  an  equal  number  of 
acknowledgements,  which  in  turn  causes  lost  segpnents,  which  triggers 
massive  retransmission.  Bad  cases  of  SWS  have  been  seen  in  which  the 
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average  segment  size  was  one-t«ith  of  the  size  the  sender  and  receiver 
were  prepared  to  deal  with,  and  the  average  number  of  retransmission  per 
successful  segments  sent  was  five. 

Happily,  SWS  is  trivial  to  avoid.  The  following  sections  describe 
two  algorithms,  one  executed  ty  the  sender,  and  one  by  the  receiver, 
which  appear  to  eliminate  SWS  completely.  Actually,  either  algorithm  by 
itself  is  sufficient  to  prevent  SWS,  and  thus  protect  a  host  from  a 
foreign  implementation  which  has  failed  to  deal  properly  with  this 
problem.  The  two  algorithms  taken  together  produce  an  additional 
reduction  in  CPU  consumption,  observed  in  practice  to  be  as  high  as  a 
factor  of  four. 

4.  I.jproved  Window  Algorithms 

The  receiver  of  data  can  take  a  very  simple  step  to  eliminate  SWS. 
When  it  disposes  of  a  small  amount  of  data,  it  can  artificially  reduce 
the  offered  window  in  subsequent  acknowledgements,  so  that  the  useable 
window  cooputed  by  the  sender  does  not  permit  the  sending  of  any  further 
data.  At  some  later  time,  when  the  receiver  has  processed  a 
substantially  larger  amount  of  incoming  data,  the  artificial  limitation 
on  the  offered  window  can  be  removed  all  at  once,  so  that  the  sender 
computes  a  sudden  large  Jump  rather  than  a  sequence  of  small  Jumps  in 
the  useable  window. 

At  this  level,  the  algorithm  is  quite  simple,  but  in  order  to 
determine  exactly  when  the  window  should  be  opened  up  again,  it  is 
necessary  to  look  at  some  of  the  other  details  of  the  implententation. 
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D^)ending  on  whether  the  window  Is  held  artificially  closed  for  a  short 
or  long  time,  two  problems  will  develop.  The  one  we  have  already 
discussed  --  never  closing  the  window  artificially  will  lead  to  SWS. 
On  the  other  hand,  if  the  window  is  only  opened  Infrequently,  the 
pipeline  of  data  in  the  network  between  the  sender  and  the  receiver  may 
have  emptied  out  while  the  sender  was  being  held  off,  so  that  a  delay  is 
Introduced  before  additional  data  arrives  from  the  sender.  This  delay 
does  reduce  throu^^kput,  but  it  does  not  consume  network  resources  or  CPU 
resources  in  the  process,  as  does  SWS.  Thus,  it  is  in  this  direction 
that  one  ought  to  overconpensate .  For  a  simple  inplementation,  a  rule 
of  thumb  that  seems  to  work  in  practice  is  to  artificially  reduce  the 
offered  window  until  the  reduction  constitutes  one  half  of  the  available 
space,  at  which  point  increase  the  window  to  advertise  the  entire  space 
again.  In  any  event,  one  ought  to  make  the  chunk  uy  which  the  window  is 
opened  at  least  permit  one  reasonably  large  segment.  (If  the  receiver 
is  so  short  of  buffers  that  it  can  never  advertise  a  large  enough  buffer 
to  permit  at  least  one  large  segaent,  it  is  hopeless  to  e^qpect  any  sort 
of  high  throughput.) 

There  is  an  algorithm  that  the  sender  can  use  to  achieve  the  same 
effect  described  above:  a  very  simple  and  elegant  rule  first  described 
by  Michael  Greenwald  at  MIT.  The  sender  of  the  data  uses  the  offered 
window  to  compute  a  useable  window,  and  then  compares  the  useable  window 
to  the  offered  window,  and  refrains  from  sending  anything  if  the  ratio 
of  useable  to  offered  is  less  than  a  certain  fraction.  Clearly,  if  the 
computed  useable  window  is  small  compared  to  the  offered  window,  this 
means  that  a  substantial  amount  of  previously  sent  information  is  still 
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in  the  pipeline  from  the  sender  to  the  receiver,  which  in  turn  means 
that  the  sender  can  count  on  being  granted  a  larger  useable  window  in 
the  future.  Until  the  useable  window  reaches  a  certain  amount,  the 
sender  should  sinply  refuse  to  send  anything. 

Simple  esqperiments  suggest  that  the  exact  value  of  the  ratio  is  not 
very  important,  but  that  a  value  of  about  25  percent  is  sufficient  to 
avoid  SWS  and  achieve  reasonable  throu^^ut,  even  for  machines  with  a 
small  offered  window.  An  additional  enhancement  which  might  help 
throughput  would  be  to  attempt  to  hold  off  sending  until  one  can  send  a 
maximum  size  segment.  Another  enhancement  would  be  to  send  anyway,  even 
if  the  ratio  is  small,  if  the  useable  window  is  sufficient  to  hold  the 
data  available  up  to  the  next  "push  point". 

This  algorithm  at  the  sender  end  is  very  simple.  Notice  that  it  is 
not  necessary  to  set  a  timer  to  protect  against  protocol  lockup  when 
postponing  the  send  operation.  Further  acknowledgements,  as  they 
arrive,  will  inevitably  change  the  ratio  of  offered  to  useable  window. 
(To  see  this,  note  that  when  all  the  data  in  the  catanet  pipeline  ha.s 
arrived  at  the  receiver,  the  resulting  acknowledgement  must  yield  an 
offered  window  and  useable  window  that  equal  each  other.)  If  the 
expected  acknowledgements  do  not  arrive,  the  retransmission  mechanisji 
will  come  into  play  to  assure  that  something  finally  happens.  Thus,  to 
add  this  algorithm  to  an  existing  TCP  ioplementation  usually  requires 
one  line  of  code.  As  part  of  the  send  algorithm  it  is  already  necessary 
to  compute  the  useable  window  from  the  offercxl  window.  It  is  a  simple 
matter  to  add  a  line  of  code  which,  if  the  ratio  is  less  than  a  certain 
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percent,  sets  the  useable  window  to  zero.  The  results  of  SWS  are  so 
devastating  that  no  sender  should  be  without  this  sinple  piece  of 
insurance . 

5.  Improved  Acknowledgement  Algorithms 

In  the  beginning  of  this  paper,  an  overly  simplistic  inplementation 
of  TCP  was  described,  which  led  to  SWS.  One  of  the  characteristics  of 
this  implementation  was  that  the  recipient  of  data  sent  a  separate 
acknowledgement  for  every  segment  that  it  received.  This  conpulsive 
acknowledgement  was  one  of  the  causes  of  SWS,  because  each 
acknowledgement  provided  some  new  useable  window,  but  even  if  one  of  the 
algorithms  described  above  is  used  to  eliminate  SWS,  overly  frequent 
acknowledgement  still  has  a  substantial  problem,  which  is  that  it 
greatly  Increases  the  processing  time  at  the  sender's  end.  Measurement 
of  TCP  inplementations,  especially  on  large  operating  systems,  indicate 
that  most  of  the  overhead  of  dealing  with  a  segment  is  not  in  the 
processing  at  the  TCP  or  IP  level,  but  sinply  in  the  scheduling  of  the 
handler  which  is  required  to  deal  with  the  segment.  A  steady  dribble  of 
acknowledgements  causes  a  high  overhead  in  scheduling,  with  very  little 
to  show  for  it.  This  waste  Is  Co  be  avoided  if  possible. 

There  are  two  reasons  for  proopt  acknowledgement.  One  is  to 
prevent  retransmission.  We  will  discuss  later  how  to  determine  whether 
unnecessary  retransmission  is  occurring.  The  other  reason  one 
acknowledges  promptly  is  to  permit  further  data  to  be  sent.  However, 
the  previous  section  makes  quite  clear  that  it  is  not  always  desirable 
to  send  a  little  bit  of  data,  even  though  the  receiver  may  have  room  for 
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it.  Therefore,  one  can  state  a  general  rule  that  under  normal 
operation,  the  receiver  of  data  need  not,  and  for  efficiency  reasons 
should  not,  acknowledge  the  data  unless  either  the  acknowledgement  is 
intended  to  produce  an  increased  useable  window,  is  necessary  in  order 
to  prevent  retransmission  or  is  being  sent  as  part  of  a  reverse 
direction  segment  being  sent  for  some  other  reason.  We  will  consider  an 
algorithm  to  achieve  these  goals. 

Only  the  recipient  of  the  data  can  control  the  generation  of 
acknowledgements.  Once  an  acknowledgement  has  been  sent  from  the 
receiver  back  to  the  sender,  the  sender  must  process  it.  Althoug^i  the 
extra  overhead  is  incurred  at  the  sender's  end,  it  is  entirely  under  the 
receiver's  control.  Therefore,  we  must  now  describe  an  algorithm  which 
occurs  at  the  receiver's  end.  Obviously,  the  algorithm  must  have  the 
following  general  form;  sometimes  the  receiver  of  data,  i^xjn  processing 
a  segpwnt,  decides  not  to  send  an  acknowledgement  now,  but  to  postpone 
the  acknowledgement  until  some  time  in  the  future,  perhaps  by  setting  a 
timer.  The  peril  of  this  approach  is  that  on  many  large  operating 
systems  it  is  extremely  costly  to  respond  to  a  timer  event,  almost  as 
costly  as  to  respond  to  an  incoming  segment.  Clearly,  if  the  receiver 
of  the  data,  in  order  to  avoid  extra  overhead  at  the  sender  end,  spends 
a  great  deal  of  time  responding  to  timer  interrupts,  no  overall  benefit 
has  been  achieved,  for  efficiency  at  the  sender  end  is  achieved  by  great 
thrashing  at  the  receiver  end.  We  must  find  an  algorithm  that  avoids 
both  of  these  perils. 

The  following  scheme  seems  a  good  conpromise.  The  receiver  of  data 
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will  refrain  from  sending  an  acknowledgement  under  certain 
circumstances,  in  which  case  it  must  set  a  timer  which  will  cause  the 
acknowledgement  to  be  sent  later.  However,  the  receiver  should  do  this 
only  where  it  is  a  reasonable  guess  that  some  other  event  will  intervene 
and  prevent  the  necessity  of  the  timer  interrupt.  The  most  obvious 
event  on  which  to  depend  is  the  arrival  of  another  segment.  So,  if  a 
segment  arrives,  postpone  sending  an  acknowledgement  if  both  of  the 
following  conditions  hold.  First,  the  push  bit  is  not  set  in  the 
segment,  since  it  is  a  reasonable  assumption  that  there  is  more  data 
coming  in  a  subsequent  segment.  Second,  there  is  no  revised  window 
information  to  be  sent  back. 

This  algorithm  will  insure  that  the  timer,  although  set,  is  seldom 
used.  The  interval  of  the  timer  is  related  to  the  e^qpected  inter - 
serpent  delay,  which  is  in  turn  a  function  of  the  particular  network 
through  which  the  data  is  flowing.  For  the  Arpanet,  a  reasonable 
interval  seems  to  be  200  to  300  milliseconds.  Appendix  A  describes  an 
adaptive  algotitna  for  measuring  this  delay. 

The  section  on  improved  window  algorithms  described  both  a  receiver 
algorithm  and  a  sender  algorithm,  and  suggested  that  both  should  be 
used.  The  reason  for  this  is  now  clear.  While  the  sender  algorithm  is 
extremely  simple,  and  useful  as  insurance,  the  receiver  algorithm  is 
required  in  order  that  this  improved  acknowledgement  strategy  work.  If 
the  receipt  of  every  segment  causes  a  new  window  value  to  be  returned, 
then  of  necessity  an  acknowledgement  will  be  sent  for  every-  data 
segment.  When,  according  to  the  strategy  of  the  previous  section,  the 
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receiver  determines  to  artificially  reduce  the  offered  window,  that  is 
precisely  the  circumstance  under  which  an  acknowledgement  need  not  be 
sent.  When  the  receiver  window  algorithm  and  the  receiver 
acknowledgement  algorithm  are  used  together,  it  will  be  seen  that 
sending  an  acknowledgement  will  be  triggered  by  one  of  the  following 
events.  First,  a  push  bit  has  been  received.  Second,  a  temporary  pause 
in  the  data  stream  is  detected.  Ihird,  the  offered  window  has  been 
artificially  reduced  to  one-half  its  actual  value. 

In  the  beginning  of  this  section,  it  was  pointed  out  that  there  are 
two  reasons  why  one  must  acknowledge  data.  Our  consideration  at  this 
point  has  been  concerned  only  with  the  first,  that  an  acknowledgement 
must  be  returned  as  part  o£  triggering  the  sending  of  new  data.  It  is 
also  necessary  to  acknowledge  whenever  the  failure  to  do  so  would 
trigger  retransmission  by  the  sender.  Since  the  retransmission  interval 
is  selected  by  the  sender,  the  receiver  of  the  data  cannot  make  a 
precise  determination  of  when  the  acknowledgement  must  be  sent. 
However,  there  is  a  rough  rule  the  sender  can  use  to  avoid 
retransmission,  provided  that  the  receiver  is  reasonably  well  behaved. 

We  will  assume  that  ser-ider  of  the  data  uses  the  optional  algorithm 
described  in  the  TCP  specification,  in  which  the  roundtrip  delay  is 
measured  using  an  exponential  decay  smoothing  algorithm.  Retransmission 
of  a  segment  occurs  if  the  measured  delay  for  that  sequent  exceeds  the 
smoothed  average  by  some  factor.  To  see  how  retransmission  might  be 
triggered,  one  must  consider  the  pattern  of  segment  arrivals  at  the 
receiver.  The  goal  of  our  strategy  was  that  the  sender  should  send  off 
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a  number  of  segments  in  '^iose  sequence,  and  receive  one  acknowledgement 
for  the  whole  burst.  The  acknowledgement  will  be  generated  by  the 
receiver  at  the  time  that  the  last  segment  in  the  burst  arrives  at  the 
receiver.  (To  ensure  the  prompt  return  of  the  acknowledgement,  the 
sender  could  turn  on  the  "push”  bit  in  the  last  segment  of  the  burst.) 
The  delay  observed  at  the  sender  between  the  initial  transmission  of  a 
serpent  and  the  receipt  of  the  acknowledgement  will  include  both  the 
network  trar^lt  time,  plus  the  holding  time  at  the  receiver.  The 
holding  time  will  be  greatest  for  the  first  segments  in  the  burst,  and 
smallest  for  the  last  se^nents  in  the  burst.  Thus,  the  smoothing 
algorithm  wll]  measure  a  delay  which  is  roughly  proportional  to  the 
average  roundtrip  delay  for  all  the  segments  in  the  burst.  Problems 
will  arise  if  the  average  delay  is  substantially  smaller  than  the 
maxinnjm  delay  and  the  smoothing  algorithm  used  has  a  very  small 
threshold  for  triggering  retransmission.  The  widest  variation  between 
average  and  maximum  delay  will  occur  when  network  transit  time  is 
negligible,  and  all  delay  is  processing  time.  In  this  case,  the  maximum 
will  be  twice  the  average  (by  sinple  alg^ra)  so  the  threshold  that 
controls  retransmission  should  be  somewhat  more  than  a  factor  of  two. 

In  practice,  retransmission  of  the  first  segments  of  a  burst  has 
not  been  a  problem  because  the  delay  measured  consists  of  the  network 
roundtrip  delay,  as  %m11  as  the  delay  due  to  withholding  the 
acknowledgement,  and  the  roundtrip  tends  to  dominate  except  in  very  low 
roundtrip  time  situations  (such  as  when  sending  to  one's  self  for  test 
purposes)  .  This  low  roundtrip  situation  can  be  covered  very  sinply  by 
irxrluding  a  minimum  value  below  which  the  roundtrip  estimate  is  not 


permitted  to  drop. 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1985 


14 

In  our  experiments  with  this  algorithm,  retransmission  due  to 
faulty  calculation  of  the  roundtrip  delay  occurred  only  once,  when  the 
parameters  of  the  e:)q>onential  smoothing  algorithm  had  been  misad justed  I 

so  that  they  were  only  taking  into  account  the  last  two  or  three 
segments  sent.  Clearly,  this  will  cause  trouble  since  the  last  two  or 
three  segments  of  any  burst  are  the  ones  whose  holding  time  at  the 
receiver  is  minimal,  so  the  resulting  total  estimate  was  much  lower  than 
appropriate.  Once  the  parai&eters  of  the  algorithm  had  been  adjusted  so 
that  the  number  of  segments  taken  into  account  was  approximately  twice 
the  number  of  segments  in  a  burst  of  average  size,  with  a  threshold 
factor  of  1.5,  no  further  retransmission  has  ever  been  identified  due  to 
this  problem.  Including  when  sending  to  ourself  and  wheri  sending  over 
high  delay  nets. 

6.  Conservative  Vs.  Optimistic  Windows 

According  to  the  TCP  specification,  the  offered  window  is  presumed 
to  have  some  relationship  to  the  amount  of  data  which  the  receiver  is 
actually  prepared  to  receive.  Ho%^ever,  it  is  not  necessarily  an  exact 
correspondence.  We  will  use  the  term  “conservative  window”  to  describe 
the  case  where  the  offered  window  is  precisely  no  larger  than  the  actual 
buffering  available.  The  drawback  to  conservative  window  algorithms  is 
that  they  can  produce  very  low  throughput  in  long  delav  situations.  It 
is  easy  to  see  that  the  maximum  input  of  a  conservative  window  algorithm 
is  one  buffer  full  every  roundtrip  delay  in  the  net,  since  the  next 
buffer full  cannot  be  launched  until  the  updated  window/acknowledgement 
information  from  the  previous  transmission  has  made  the  roundtrip. 
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In  certain  cases,  it  may  be  possible  to  increase  the  overall 
throug^ut  of  the  transmission  by  increasing  the  offered  window  over  the 
actual  buffer  available  at  the  receiver.  Such  a  strategy  we  will  call 
an  "optimistic  window"  strategy.  The  optimistic  strategy  works  if  the 
network  delivers  the  data  to  the  recipient  sufficiently  slowly  that  it 
can  process  the  data  fast  enough  to  ke^  the  buffer  from  overflowing. 
If  the  receiver  is  faster  than  the  sender,  one  could,  with  luck,  permit 
an  infinitely  qptimistic  window,  in  which  the  sender  is  simply  permitted 
to  send  full -speed.  If  the  sender  is  faster  than  the  receiver,  however, 
and  the  window  is  too  optimistic,  then  some  segoaents  will  cause  a  buffer 
overflow,  and  will  be  discarded.  Therefore,  the  correct  strategy  to 
implement  an  qptimistic  window  is  to  increase  the  window  size  until 
segnents  start  to  be  lost.  This  only  works  if  it  is  possible  to  detect 
that  the  segment  has  been  lost.  In  some  cases,  it  is  easy  to  do, 
because  the  segnent  is  partially  processed  inside  the  receiving  host 
before  it  is  thrown  away.  In  other  cases,  overflows  may  actually  cause 
the  netwc 'k  interface  to  be  clogged,  which  will  cause  the  segnents  to  be 
lost  elsewhere  in  the  net.  It  is  inadvisable  to  attempt  an  optimistic 
window  strategy  unless  one  is  certain  that  the  algorithm  can  detect  the 
resulting  lost  segnents.  However,  the  increase  in  throug^hput  which  is 
possible  from  optimistic  windows  is  quite  substantial.  Any  systems  with 
small  buffer  space  should  seriously  consider  the  merit  of  optimistic 
windows . 

The  selection  of  an  appropriate  window  algorithm  is  actually  more 
cooplicated  than  even  the  above  discussion  suggests.  The  following 
considerations  are  not  presented  with  the  Intention  that  they  be 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1985 


16 

incorporated  in  currer.t  inplementations  of  TCP,  but  as  background  for 
the  sophisticated  designer  who  is  attenpting  to  understand  how  his  TCP 
will  respond  to  a  variety  of  networks,  with  different  speed  and  delay 
characteristics.  The  particular  pattern  of  windows  and  acknowledgements 
sent  from  receiver  to  sender  influences  two  characteristics  of  the  data 
being  sent.  First,  they  control  the  average  data  rate.  Clearly,  the 
average  rate  of  the  sender  cannot  exceed  the  average  rate  of  the 
receiver,  or  long-term  buffer  overflow  will  occur.  Second,  they 
Influence  the  burstiness  of  the  data  coming  from  the  sender.  Burst iness 
has  both  advantages  and  disadvantages.  The  advantage  of  burstiness  is 
that  it  reduces  the  CPU  processing  necessary  to  send  the  data.  This 
follows  from  the  observed  fact,  especially  on  large  machines,  that  most 
of  the  cost  of  sending  a  segment  is  not  the  TCP  or  IP  processing,  but 
the  scheduling  overhead  of  getting  started. 

On  the  other  hand,  the  disadvantage  of  burstiness  is  that  it  may 
cause  buffers  to  overflow,  either  in  the  eventual  recipient,  which  was 
discussed  above,  or  in  an  intermediate  gateway,  a  problem  Ignored  in 
this  paper.  The  algorithms  described  above  attenpts  to  strike  a  balance 
between  excessive  burstiness,  which  in  the  extreme  cases  can  cause 
delays  because  a  burst  is  not  requested  soon  enough,  and  excessive 
fragmentation  of  the  data  stream  into  small  segments,  which  we 
identified  as  Silly  Window  Syndrome. 

Under  conditions  of  extreme  delay  in  the  network,  none  of  the 
algorithms  described  above  will  achieve  adequate  throughput. 
Conservative  window  algorithms  have  a  predictable  throughput  limit. 
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which  is  one  windowful  1  per  roundtrip  delay.  Attenpts  to  solve  this  by 
optimistic  window  strategies  may  cause  buffer  overflows  due  to  the 
bursty  nature  of  the  arriving  data.  A  very  sophisticated  way  to  solve 
this  is  for  the  receiver,  having  measured  by  some  means  the  roundtrip 
delay  and  intersegment  arrival  rate  of  the  actual  connection,  to  open 
his  window,  not  in  one  optimistic  increment  of  gigantic  proportion,  but 
in  a  number  of  smaller  c^timistic  increments,  which  have  been  carefully 
spaced  using  a  timer  so  that  the  resulting  smaller  bursts  which  arrive 
are  each  sufficiently  small  to  fit  into  the  existing  buffers.  One  could 
visualize  this  as  a  number  of  requests  flowing  backwards  through  the  net 
which  trigger  in  return  a  number  of  bursts  which  flow  back  spaced  evenly 
from  the  sender  to  the  receiver.  The  overall  result  is  that  the 
receiver  uses  the  window  mechanism  to  control  the  burstiness  of  the 
arrivals,  and  the  average  rate. 

To  my  knowledge,  no  such  strategy  has  been  implemented  in  any  TCP. 
First,  we  do  not  normally  nave  delays  hig^  enough  to  require  this  kind 
of  treatment.  Second,  the  strategy  described  above  is  probably  not 
stable  unless  it  is  very  carefully  balanced.  Just  as  buses  on  a  single 
bus  route  tend  to  bunch  up,  bursts  which  start  out  equally  spaced  could 
vrell  end  vp  piling  into  each  other,  and  forming  the  single  large  burst 
which  the  receiver  was  hoping  to  avoid.  It  is  inportant  to  understand 
this  extreme  case,  however,  in  order  to  understand  the  limits  beyond 
which  TCP,  as  normally  implemented,  witti  either  conservative  or  simple 
optimistic  windows  can  be  expected  to  deliver  throug^ut  which  is  a 
reasonable  percentage  of  the  actual  network  capacity. 
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7 .  Conclusions 

This  paper  describes  three  sinple  algorithms  for  performance 
enhancement  In  TCP,  one  at  the  sender  end  and  two  at  the  receiver.  The 
sender  algorithm  is  to  refrain  from  sending  if  the  useable  window  is 
smaller  than  25  percent  of  the  offered  window.  The  receiver  algorithms 
are  first,  to  artificially  reduce  the  offered  window  when  processing  new 
data  if  the  resulting  reduction  does  not  represent  more  than  some 
fraction,  say  50  percent,  of  the  actual  space  available,  and  second,  to 
refrain  from  sending  an  acknowledgment  at  all  if  two  simple  conditions 
hold. 


Either  of  these  algorithms  will  prevent  the  worst  aspects  of  Silly 
Window  Syndrome,  and  when  these  algorithms  are  used  together,  they  will 
produce  substantial  Inprovement  in  CPU  utilization,  by  eliminating  the 
process  of  excess  acknowledgements. 

Preliminary  ejg^eriments  with  these  algorithms  suggest  that  they 
work,  and  work  very  ’'ell.  Both  the  sender  and  receiver  algorithms  have 
been  shovm  to  eliminate  SWS,  even  when  talking  to  fairly  silly 
algorithms  at  the  ether  end.  The  Multics  mailer,  in  particular,  had 
suffered  si.±>stantial  attacl<cs  of  SWS  while  sending  large  mail  to  a  number 
of  hosts.  We  br>lleve  that  Inplementation  of  the  sender  side  algorithm 
has  eliminated  every  known  case  of  SWS  detected  in  our  mailer. 
Iqplementatlon  of  the  receiver  side  algorithm  produced  substantial 
improvements  of  CPU  time  when  Multics  was  the  sending  system.  Multics 
is  a  typical  large  operating  system,  with  scheduling  costs  which  are 
large  compared  to  the  actual  processing  time  for  protocol  handlers. 
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Tests  were  done  sending  from  Mai  tics  to  a  host  v^ich  inplemented  the  SWS 
suppression  algorithm,  and  which  could  either  refrain  or  not  from 
sending  acknowledgements  on  each  segment.  As  predicted,  suppressing  the 
return  acknowledgements  did  not  influence  the  throughput  for  large  data 
transfer  at  all,  since  the  throttling  effect  was  else\diere.  However, 
the  CPU  time  required  to  process  the  data  at  the  Multics  end  was  cut  by 
a  factor  of  four  (In  this  experiment,  the  bursts  of  data  which  were 
being  sent  were  approximately  eig^t  segments.  Thus,  the  number  of 
acknowledgements  in  the  two  esqperiments  differed  by  a  factor  of  eig^t.) 

An  important  consideration  in  evaluating  these  algorithms  is  that 
they  must  not  cause  the  protocol  implementations  to  deadlock.  All  of 
the  recommendations  in  this  document  have  the  characteristic  that  they 
suggest  one  refrain  from  doing  something  even  thougih  the  protocol 
specification  permits  one  to  do  it.  The  possibility  exists  that  if  one 
refrains  from  doing  something  now  one  may  never  get  to  do  it  later,  and 
both  ends  will  halt,  even  thougpn  it  would  appear  svperficially  that  the 
transaction  can  continue. 

Formally,  the  idea  that  things  continue  to  work  is  referred  to  as 
"liveness".  One  of  the  defects  of  ad  hoc  solutions  to  performance 
problems  is  the  possibility  that  two  different  approaches  will  interact 
to  prevent  liveness.  It  is  believed  that  the  algorithms  described  in 
this  paper  are  always  live,  and  that  is  one  of  the  reasons  why  there  is 
a  strong  advantage  in  uniform  uso  of  this  particular  proposal,  except  in 
cases  where  it  is  e^qplicitly  demonstrated  not  to  work. 

The  argument  for  liveness  in  these  solutions  proceeds  as  follows. 
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First,  the  sender  algorithm  can  only  be  stopped  by  one  thing,  a  refusal 
of  the  receiver  to  acknowledge  sent  data.  As  long  as  the  receiver 
continues  to  acknowledge  data,  the  ratio  of  useable  window  to  offered 
window  will  approach  one,  and  eventually  the  sender  must  continue  to 
send.  However,  notice  that  the  receiver  algorithm  we  have  advocated 
involves  refraining  from  acknowledging.  Therefore,  we  certainly  do  have 
a  situation  where  inproper  op>eration  of  this  algorithm  can  prevent 
liveness . 

What  we  must  show  is  that  the  receiver  of  the  data,  if  it  chooses 
to  refrain  from  acknowledging,  will  do  so  only  for  a  short  time,  and  not 
forever.  The  design  of  the  algorithm  described  above  was  intended  to 
achieve  precisely  this  goal:  whenever  the  receiver  of  data  refrained 
from  sending  an  acknowledgement  it  was  required  to  set  a  timer.  The 
only  event  that  was  permitted  to  clear  that  timer  was  the  receipt  of 
another  segment,  which  essentially  reset  the  timer,  and  started  it  going 
again.  Thus,  an  acknowledgement  will  be  sent  as  soon  as  no  data  has 
been  received.  This  has  precisely  the  effect  desired:  if  the  data  flow 
appears  to  be  disrupted  for  any  reason,  the  receiver  responds  by  sending 
an  up-to-date  acknowledgement.  In  fact,  the  receiver  algorithm,  is 
designed  to  be  more  robust  than  this,  for  transmission  of  an 
acknowledgment  is  triggered  by  two  events,  either  a  cessation  of  data  or 
a  reduction  in  the  amount  of  offered  window  to  50  percent  of  the  actual 
value.  This  is  the  condition  which  will  normally  trigger  the 
transmission  of  this  acknowledgement. 


IMPLEMENTATION  GUIDELINES 


RFC  813 


21 

APPENDIX  A 

Dynoinic  Calculation  of  Acknowledgement  Delay 

The  text  suggested  \hat  when  setting  a  timer  to  postpone  the 
sending  of  an  acknowledgement,  a  fixed  interval  of  200  to  300 
milliseconds  would  work  properly  in  practice.  This  has  not  been 
verified  over  a  wide  variety  of  network  delays,  and  clearly  if  there  is 
a  very  slow  net  which  stretches  out  the  intersegment  arrival  time,  a 
fixed  interval  will  fail.  In  a  sophisticated  TCP,  which  is  expected  to 
adjust  dynamically  (rather  than  manually)  to  changing  network 
conditions,  it  would  bo  appropriate  to  measure  this  interval  and  respond 
dynamically.  The  following  algorithm,  which  has  been  relegated  to  an 
J^ppendix,  because  it  has  not  been  tested,  seems  sensible.  Whenever  a 
segment  arrives  which  does  not  have  the  push  bit  on  in  it,  start  a 
timer,  which  runs  until  the  next  segment  arrives.  Average  these 
inter arrival  intervals,  using  an  ejqponentlal  decay  smoothing  function 
tuned  to  take  into  account  perhaps  the  last  ten  or  twenty  segments  that 
have  coma  in.  Occasionally,  there  will  be  a  long  intorarrival  period, 
even  for  a  segment  \^ch  is  does  not  terminate  a  piece  of  data  being 
pushed,  perhaps  because  a  window  has  gone  to  zero  or  some  glitch  in  the 
sender  or  the  network  has  held  up  the  data.  Therefore,  examine  each 
Interarrival  interval,  and  discard  it  from  the  smoothing  algorithm  if  it 
exceeds  the  current  estimate  by  some  amount,  perhaps  a  ratio  of  two  or 
four  times.  By  rejecting  the  larger  lnterso^p«nt  arrival  intervals,  one 
should  obtain  a  smoothed  estimate  of  the  interarrival  of  segments  inside 
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that  net.  Service  names  are  translated  into  a  "port  identifier",  v^hich 
in  TCP  is  a  16-bit  value.  Finally,  addresses  are  translated  into 
"routes",  vhich  are  the  sequence  of  steps  a  packet  must  take  to  reach 
the  specified  addresses.  Routes  show  up  explicitly  in  the  form  of  the 
internet  routing  options,  and  also  implicitly  in  the  address  to  route 
translation  tables  which  all  hosts  and  gateways  maintain. 


This  RFC  gives  suggestions  and  guidance  for  the  design  of  the 


tables  and  algorithms  necessary  to  keep  track  of  these  various  sorts  of 
identifiers  inside  a  host  implementation  of  TCP/IP. 
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2.  The  Scope  of  the  Problem 

One  of  the  first  questions  one  can  ask  about  a  naming  mechanism  Is 
how  many  names  one  can  expect  to  encounter.  In  order  to  answer  this.  It 
Is  necessary  to  !<now  something  about  the  expected  maximum  size  of  the 
Internet.  Currently,  the  Internet  Is  fairly  small.  It  contains  no  more 
than  25  active  networks,  and  no  more  than  a  few  hundred  hosts.  This 
makes  It  possible  to  Install  tables  which  exhaustively  list  all  of  these 
elements.  However,  any  implementation  undertaken  now  should  be  based  on 
an  assumption  of  a  much  larger  Inteniet.  The  guidelines  currently 
recommended  are  ai\  upper  limit  of  about  1,000  networks.  If  we  Imagine 
an  average  number  of  25  hosts  per  net,  this  would  suggest  a  maximum 
number  of  25,000  hosts.  It  Is  quite  unclear  whether  this  host  estimate 
Is  hl^  or  low,  but  even  If  It  Is  off  by  several  factors  of  two,  the 
resulting  number  Is  still  large  enough  to  suggest  that  current  table 
management  strategies  are  unacceptable.  Some  frcssh  techniques  will  be 
required  to  deal  with  the  Internet  of  the  future. 

3 .  Names 

As  the  previous  section  suggests,  the  Internet  will  eventually  have 
a  sufficient  number  of  names  that  a  host  cannot  liave  a  static  table 
v^ch  provides  a  translation  from  every  name  to  Its  associated  address. 
There  are  several  reasons  other  than  sheer  size  why  a  host  would  not 
wish  to  have  such  a  table.  First,  with  that  many  names,  we  can  expect 
names  to  be  added  and  deleted  at  such  a  rate  that  an  Installer  might 
spend  all  his  time  Just  revising  the  cable.  Second,  most  of  the  names 
will  refer  to  addresses  of  machines  with  which  nothing  will  ever  be 


EVIPLEMENTATION  GUIDELINES 


RFC  814 


3 

exchanged.  In  fact,  there  may  be  vfhole  networks  with  >^ch  a  particular 
host  will  never  have  any  traffic. 

To  cope  with  this  large  and  somewhat  dynamic  environment,  the 
internet  is  moving  from  its  current  position  in  which  a  single  name 
table  is  maintained  by  the  NIC  and  distributed  to  all  hosts,  to  a 
distributed  approach  in  which  each  network  (or  group  of  networks)  is 
responsible  for  maintaining  its  own  names  and  providing  a  "name  server” 
to  translate  between  the  names  and  addresses  in  that  network.  Each 
host  is  assumed  to  store  not  a  complete  set  of  name-address 
translations,  but  only  a  cache  of  recently  used  names.  When  a  name  is 
provided  by  a  user  for  translation  to  an  address,  the  host  will  first 
examine  its  local  cache,  and  if  the  name  is  not  found  there,  will 
communicate  with  an  appropriate  name  server  to  obtain  the  information, 
which  it  may  then  Insert  into  its  cache  for  future  reference. 

Unfortunately,  the  name  server  mechanism  is  not  totally  in  place  in 
the  internet  yet,  so  for  the  moment,  it  is  necessary  to  continue  to  use 
the  old  strat€5gy  of  maintaining  a  complete  table  of  all  names  in  every 
host.  Inplementors,  however,  should  structure  this  table  in  such  a  way 
that  it  is  eas>'  to  convert  later  to  a  name  server  approach.  In 
particular,  a  reasonable  prograioning  strategy  would  be  to  make  the  name 
table  accessible  only  through  a  subroutine  Interface,  rather  than  by 
scattering  direct  references  to  the  table  all  throuq^h  the  code.  In  this 
way,  it  will  be  possible,  at  a  later  date,  to  replace  the  subroutine 
with  one  capable  of  making  calls  on  remote  name  servers. 


A  problem  which  occasionally  arises  in  the  ARPANET  today  is  that 
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the  Information  In  a  local  host  table  Is  out  of  date,  because  a  host  has 
moved,  and  a  revision  of  the  host  table  has  not  yet  been  installed  from 
the  NIC.  In  this  case,  one  atteDopts  to  connect  to  a  particular  host  and 
discovers  an  une^q^ected  machine  at  the  address  obtained  from  the  local 
table.  If  a  human  is  directly  observing  the  connection  attempt,  the 
error  is  usually  detected  immediately.  However,  for  unattended 
operations  such  as  the  ser^ding  of  queued  mail,  this  sort  of  problem  can 
lead  to  a  great  deal  of  confusion. 

The  namaserver  scheme  will  only  make  this  problem  worse,  if  hosts 
cache  locally  the  address  associated  with  names  that  have  been  looked 
up,  because  the  host  has  no  way  of  knowing  when  the  address  has  changed 
and  the  cache  entry  should  be  removed.  To  solve  this  problem,  plans  are 
currently  under  way  to  define  a  simple  facility  by  which  a  host  can 
query  a  foreign  address  to  determine  %diat  name  is  actually  associated 
with  it.  SMTP  already  defines  a  verification  technique  based  on  this 
approach. 

4.  Addresses 

The  IP  layer  must  know  something  about  addresses.  In  particular, 
when  a  datagram  is  being  sent  out  from  a  host,  the  IP  layer  must  decide 
%d)ere  to  send  it  on  the  inmediately  connected  network,  based  on  the 
internet  address.  Mechanically,  the  IP  first  tests  the  internet  address 
to  see  whether  the  network  number  of  the  recipient  is  the  same  as  the 
network  number  of  the  sender.  If  so,  the  packet  can  be  sent  directly  to 
the  final  recipient.  If  not,  the  datagram  must  be  sent  to  a  gateway  for 
further  forwarding.  In  this  latter  case,  a  second  decision  must  be 


made,  as  there  may  be  more  than  one  gateway  available  on  the  immediately 


attached  network. 


When  the  internet  address  format  was  first  specified,  8  bits  were 


reserved  to  identify  the  network.  Early  implementations  thus 
implemented  the  above  algorithm  by  means  of  a  table  with  256  entries, 
one  for  each  possible  net,  that  specified  the  gateway  of  choice  for  that 


net,  with  a  special  case  entry  for  those  nets  to  which  the  host  was 


inmadiately  connected.  Such  tables  were  sometimes  statically  filled  in. 


^^ch  caused  confusion  and  malfunctions  when  gateways  and  networks  moved 


(or  crashed) . 


The  current  definition  of  the  internet  address  provides  three 


different  options  for  network  numbering,  with  the  goal  of  allowing  a 


very  large  number  of  networks  to  be  part  of  the  internet.  Thus,  it  is 


no  longer  possible  to  imagine  having  an  exhaustive  table  to  select  a 


gateway  for  any  forei^i  net.  Again,  current  implementations  must  use  a 


strategy  based  on  a  local  cache  of  routing  information  for  addresses 


currently  being  used. 


The  recommended  strategy  for  address  to  route  translation  is  as 


follows.  When  the  IP  layer  receives  an  outbound  datagram  for 


transmission,  it  extracts  the  network  number  from  the  destination 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1985 


accessible  gateway  at  random,  insert  that  as  an  entry  in  the  table,  and 
use  it  to  send  the  packet.  Either  the  guess  will  be  rig^t  or  wrong.  If 
it  is  wrong,  uhe  gateway  to  which  the  packet  was  sent  will  return  an 
ICMP  redirect  message  to  report  that  there  is  a  better  gateway  to  reach 
the  net  in  question.  Ihe  arrival  of  this  redirect  should  cause  an 
update  of  the  local  table. 

The  number  of  entries  in  the  local  table  should  be  aatermlned  by 
the  maximum  number  of  active  connections  which  this  particular  host  can 
support  at  any  one  time.  For  a  large  time  sharing  system,  one  might 
imagine  a  table  with  100  or  more  entries.  For  a  personal  conputer  being 
used  to  support  a  single  user  telnet  connection,  only  one  address  to 
gateway  association  need  be  maintained  at  once. 

The  above  strategy  actually  does  not  conpletely  solve  the  problem, 
but  only  pushes  it  down  one  level,  where  the  problem  then  arises  of  how 
a  new  host,  freshly  arriving  on  the  internet,  finds  all  of  its 
accessible  gateways.  Intentionally,  this  problem  is  not  solved  within 
the  internetwork  architecture.  The  reason  is  that  different  networks 
have  drastically  different  strategies  for  allowing  a  host  to  find  out 
about  other  hosts  on  its  Immediate  network.  Some  nets  permit  a 
broadcast  mechanism.  In  this  case,  a  host  can  send  out  a  message  and 
e^qpect  an  answer  back  from  all  of  the  attached  gateways.  In  other 
cases,  where  a  particular  network  is  richly  provided  with  tools  to 
support  the  internet,  there  may  be  a  special  network  mechanism  which  a 
host  can  invoke  to  determine  where  the  gateways  are  In  other  cases,  it 
may  be  necessary  for  an  installer  to  manually  provide  the  name  of  at 
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least  one  accessible  gateway.  Once  a  host  has  discovered  the  name  of 
one  gateway,  it  can  build  up  a  table  of  all  other  available  gateways,  by 
keeping  track  of  every  gateway  that  has  been  reported  back  to  it  in  an 
ICMP  message. 

5.  Advanced  Topics  in  Addressing  and  Routing 

The  preceding  discussion  describes  the  mechanism  required  in  a 
minimal  inplementation,  an  inplementation  intended  only  to  provide 
operational  service  access  today  to  the  various  networks  that  make  up 
the  internet.  For  any  host  which  will  participate  in  future  research, 
as  contrasted  with  service,  some  additional  features  are  required. 
Those  features  will  also  be  helpful  for  service  hosts  if  they  wish  to 
obtain  access  to  some  of  the  more  exotic  networks  which  will  become  part 
of  the  Internet  over  the  next  few  years.  All  inplementors  are  urged  to 
at  least  provide  a  structure  into  >^ch  these  features  could  be  later 
integrated . 

There  are  several  features,  either  already  a  part  of  the 
architecture  or  now  under  development,  which  are  used  to  modify  or 
e^qpand  the  relationships  between  addresses  and  routes.  The  IP  source 
route  options  allow  a  host  to  explicitly  direct  a  datagram  throu^  a 
series  of  gateways  to  its  foreign  host.  An  alternative  form  of  the  ICMP 
redirect  packet  has  been  proposed,  which  would  return  information 
specific  to  a  particular  destination  host,  not  a  destination  net. 
Finally,  additional  IP  options  have  been  proposed  to  identify  particular 
routes  within  the  internet  that  are  unacceptable.  The  difficulty  with 
inplementing  these  new  features  is  that  the  mechanisms  do  not  lie 
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entirely  within  the  bounds  of  IP.  All  the  mechanisms  above  are  designed 
to  apply  to  a  particular  connection,  so  that  their  use  must  be  specified 
at  the  TCP  level.  Thus,  tlie  interface  between  IP  and  the  layers  above 
it  must  include  mechanisms  to  allow  passing  this  information  back  and 
forth,  and  TCP  (or  any  other  protocol  at  this  level,  such  as  UDP) ,  must 
be  pr^ared  to  store  this  information.  The  passing  of  information 
between  IP  and  TCP  is  made  more  conplicated  by  the  fact  that  some  of  the 
information,  in  particular  ICMP  packets,  may  arrive  at  any  time.  The 
normal  interface  envisioned  between  TCP  and  IP  is  one  across  which 
packets  can  be  sent  or  received.  The  existence  of  asynchronous  ICMP 
messages  implies  that  there  must  be  an  additional  channel  between  the 
two,  unrelated  to  the  actual  sending  and  receiving  of  data.  (In  fact, 
there  are  many  other  ICMP  messages  which  arrive  asynchronously  and  which 
must  be  passed  from  IP  up  to  higher  layers.  See  RFC  816,  Fault 
Isolatioii  and  Recovery.) 

Source  routes  are  already  in  use  in  the  internet,  and  many 
implementations  will  wish  to  be  able  to  take  advantage  of  them.  The 
following  sorts  of  usages  should  be  permitted.  First,  a  user,  when 
initiating  a  TCP  connection,  should  be  able  to  hand  a  source  route  into 
TCP,  which  in  turn  must  hand  the  source  route  to  IP  with  every  outgoing 
datagram.  The  user  might  initially  obtain  the  source  route  by  querying 
a  different  son:  of  name  server,  which  would  return  a  source  route 
Instead  of  an  address,  or  the  user  may  have  fabricated  the  source  route 
manually.  A  TCP  which  is  listening  for  a  connection,  rather  than 
attenpting  to  open  one,  must  be  prepared  to  receive  a  datagram  which 
contains  a  IP  return  route,  in  which  case  it  must  remember  this  return 
route,  and  use  it  as  a  source  route  on  all  returning  datagrams. 
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6.  Ports  and  Service  Identifiers 

Ttie  IP  layer  of  the  architecture  contains  the  address  information 
which  specifies  the  destination  host  to  which  the  datagram  is  being 
sent.  In  fact,  datagrams  are  not  intended  just  for  particular  hosts, 
but  for  particular  agents  within  a  host,  processes  or  other  entities 
that  are  the  actual  source  and  sink  of  the  data.  IP  performs  only  a 
very  siicple  dispatching  once  the  datagram  has  arrived  at  the  target 
host,  it  dispatches  it  to  a  particular  protocol.  It  is  the 
responsibility  of  that  protocol  handler,  for  example  TCP,  to  fini^ 
di^atching  the  datagram  to  the  particular  connection  for  which  it  is 
destined.  This  next  layer  of  dispatching  is  done  using  "port 
identifiers",  which  are  a  part  of  the  header  of  the  higher  level 
protocol,  and  not  the  IP  layer. 

This  two- layer  dispatching  architecture  has  caused  a  problem  for 
certain  inplementations .  In  particular,  some  implementations  have 
wi^ed  to  put  the  IP  layer  within  the  kernel  of  the  operating  system, 
and  the  TCP  layer  as  a  user  domain  application  program.  Strict 
adherence  to  this  partitioning  can  lead  to  grave  performance  problems, 
for  the  datagram  must  first  be  dispatched  from  the  kernel  to  a  TCP 
process,  which  then  dispatches  the  datagram  to  its  final  destination 
process.  The  overhead  of  scheduling  this  dispatch  process  can  severely 
limit  the  achievable  throughput  of  the  inplementation. 

As  is  discussed  in  RFC  817,  Modularity  and  Efficiency  in  Protocol 
Implementations,  this  particular  separation  between  kerne]  ani  user 
leads  to  other  performance  problems,  even  ignoring  the  issue  of  port 
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level  dispatching.  However,  there  is  an  acceptable  shortcut  which  can 
be  taken  to  move  the  hi^er  level  dispatching  function  into  the  IP 
layer,  if  this  makes  the  implementation  substantially  easier. 

In  principle,  every  higher  level  protocol  could  have  a  different 
dispatching  algorithm.  The  reason  for  this  is  discussed  below. 
However,  for  the  protocols  involved  in  the  service  offering  being 
implemented  today,  TCP  and  UDP,  the  dispatching  algorithm  is  exactly  the 
same,  and  the  port  field  is  located  in  precisely  the  same  place  in  the 
header.  Therefore,  unless  one  is  interested  in  participating  in  further 
protocol  research,  there  is  only  one  higher  level  dispatch  algorithm. 
This  algorithm  takes  into  account  the  internet  level  foreign  address, 
the  protocol  number,  and  the  local  port  and  foreign  port  from  the  higher 
level  protocol  header.  This  algorithm  can  be  implemented  as  a  sort  of 
adjunct  to  the  IP  layer  implementation,  as  long  as  no  other  higher  level 
protocols  are  to  be  inplemented.  (Actually,  the  above  statement  is  only 
partially  true,  in  that  the  UDP  dispatch  function  is  subset  of  the  TCP 
dispatch  function.  UDP  dispatch  d^>ends  only  protocol  number  and  local 
port.  However,  there  is  an  occasion  within  TCP  when  this  exact  same 
subset  comes  into  play,  when  a  process  wishes  to  listen  for  a  connection 
from  any  foreign  host.  Thus,  the  range  of  mechanisms  necessary  to 
svjqp^ort  TCP  dispatch  are  also  sufficient  to  support  precisely  the  UDP 
requirement . ) 

The  decision  to  remove  port  level  dispatciiing  from  IP  to  the  higher 
level  protocol  has  been  questioned  by  some  implementors.  It  has  been 
argued  that  if  all  of  the  address  structure  were  part  of  the  IP  layer. 
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then  IP  could  do  all  of  the  packet  dispatching  function  within  the  host, 
which  would  lead  to  a  slnpler  modularity.  Three  problems  were 
Identified  with  this.  First,  not  all  protocol  implementors  could  agree 
on  the  size  of  the  port  identifier.  TCP  selected  a  fairly  short  port 
identifier,  16  bits,  to  reduce  header  size.  Other  protocols  being 
designed,  however,  wanted  a  larger  port  identifier,  perhaps  32  bits,  so 
that  the  port  identifier,  if  properly  selected,  could  be  considered 
probabilistically  unique.  Ihus,  constraining  the  port  id  to  one 
particular  IP  level  mechanism  would  prevent  certain  fruitful  lines  of 
research.  Second,  ports  servo  a  special  function  in  addition  to 
datagram  delivery:  certain  port  numbers  are  reserved  to  identify 
particular  services.  Thus,  TCP  port  23  is  the  remote  login  service.  If 
ports  were  implemented  at  the  IP  level,  then  the  assignment  of  well 
known  ports  could  not  be  done  on  a  protocol  basis,  but  would  have  to  be 
done  in  a  centralized  manner  for  all  of  the  IP  architecture.  Third,  IP 
was  designed  with  a  very  simple  layering  role:  IP  contained  exactly 
thoso  functions  that  the  gateways  must  understand.  If  the  port  idea  had 
been  made  a  part  of  the  IP  layer,  it  would  have  suggested  that  gateways 
needed  to  know  about  ports,  which  is  not  the  case. 


There  are,  of  course,  other  ways  to  avoid  these  problems.  In 
particular,  the  "well-known  pore"  problem  can  be  solved  by  devising  a 
second  mechanism,  distinct  from  port  dispatching,  to  name  well-kncwn 
ports.  Several  protocols  have  settled  on  the  idea  of  including,  in  the 
packet  which  sets  ip  a  connection  to  a  particular  service,  a  more 
general  service  descriptor,  such  as  a  character  string  field.  These 
special  packets,  which  are  requesting  connection  to  a  particular 
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service,  are  routed  on  arrival  to  a  special  server,  sometimes  called  a 
"rendezvous  server",  which  examines  the  service  request,  selects  a 
random  port  which  is  to  be  used  for  this  instance  of  the  service,  and 
then  passes  the  packet  along  to  the  service  itself  to  commence  the 
interaction . 

For  the  internet  architecture,  this  strategy  had  the  serious  flaw 
that  it  presumed  all  protocols  would  fit  into  the  same  service  paradigm: 
an  initial  setup  i^ase,  which  might  contain  a  certain  overhead  such  as 
Indirect  routing  through  a  rendezvous  server,  followed  by  the  packets  of 
the  interaction  Itself,  which  would  flow  directly  to  the  process 
providing  the  service.  Unfortuunately,  not  all  hig^  level  protocols  in 
internet  were  e^g^ected  to  fit  this  model.  The  best  exanple  of  this  is 
isolated  datagram  exchange  using  UDP.  The  simplest  exchange  in  UDP  is 
one  process  sending  a  single  datagram  to  another.  Especially  on  a  local 
net,  where  the  net  related  overhead  is  very  low,  this  kind  of  simple 
single  datagram  Interchange  can  be  extremely  efficient,  with  very  low 
overhead  in  the  hosts.  However,  since  these  individual  packets  would 
not  be  part  of  an  established  connection,  if  IP  supported  a  strategy 
based  on  a  rendezvous  server  and  service  descriptors,  every  isolated 
datagram  would  have  to  be  routed  indirectly  in  the  receiving  host 
through  the  rendezvous  server,  which  would  substantially  Increase  the 
overhead  of  processing,  and  every  datagram  would  have  to  carry  the  full 
service  request  field,  which  would  increase  the  size  of  the  packet 
header . 

In  general,  if  a  network  is  intended  for  "virtual  circuit  service". 
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or  tihings  similar  to  that#  then  using  a  special  hi^^  overhead  mechanism 
for  circuit  setuqp  makes  sense.  However#  current  directions  in  research 
are  leading  away  from  this  class  of  protocol#  so  once  again  the 
architecture  was  designed  not  to  preclude  alternative  protocol 
structures.  The  only  rational  position  was  that  the  particular 
dispatching  strategy  used  should  be  part  of  the  higher  level  protocol 
design#  not  the  IP  layer. 

This  same  argument  about  circuit  setup  mechanisms  also  applies  to 
the  design  of  the  IP  address  structure.  Many  protocols  do  not  transmit 
a  full  address  field  as  part  of  every  packet#  but  rather  transmit  a 
short  identifier  which  is  created  as  part  of  a  circuit  setup  from  source 
to  destination.  If  the  full  address  needs  to  be  carried  in  only  the 
first  packet  of  a  long  exchange#  then  the  overhead  of  carrying  a  very 
long  address  field  can  easily  be  justified.  Under  these  circumstances# 
one  can  create  truly  extravagant  address  fields#  which  are  capable  of 
extending  to  address  almost  any  conceivable  entity.  However#  this 
strategy  is  useable  only  in  a  virtual  circuit  net#  where  the  packets 
being  transmitted  are  part  of  a  established  sequence#  otherwise  this 
large  extravagant  address  must  be  transported  on  every  packet.  Since 
Internet  explicitly  rejected  this  restriction  cn  the  architecture,  it 
was  necessary  to  come  up  with  an  address  field  that  was  conpact  enough 
to  be  sent  in  every  datagram#  but  general  enough  to  correctly  route  the 
datagram  through  the  catanet  without  a  previous  setup  phase.  The  IP 
address  of  32  bits  is  the  conpromise  that  results.  Clearly  it  requires 
a  substantial  amount  of  shoehoming  to  address  all  of  the  interesting 
place.s  in  the  universe  with  only  32  bits.  On  the  other  hand,  had  the 
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address  field  becdme  much  bigger,  IP  would  have  been  susceptible  to 
another  criticism,  which  is  that  the  header  had  grown  unworkably  large. 
Again,  the  fundamental  design  decision  was  that  the  protocol  be  designed 
in  such  a  way  that  it  supported  research  in  new  and  different  sorts  of 
protocol  architectures. 

There  are  some  limited  restrictions  inposed  by  the  IP  design  on  the 
port  mechanism  selected  by  the  higher  level  process.  In  particular, 
when  a  packet  goes  awry  somewhere  on  the  internet,  the  offending  packet 
is  returned,  along  with  an  error  indication,  as  part  of  an  lO^  packet. 
An  ICMP  packet  returns  only  the  IP  layer,  and  the  next  64  bits  of  the 
original  datagram.  Thus,  any  higher  level  protocol  which  wishes  to  sort 
out  from  which  port  a  particular  offending  datagram  came  must  make  sure 
that  the  port  information  is  contained  within  the  first  64  bits  of  the 
next  level  header.  This  also  means,  in  most  cases,  that  it  is  possible 
to  imagine,  as  part  of  the  IP  layer,  a  port  dispatch  mechanism  which 
works  by  masking  and  matching  on  the  first  64  bits  of  the  incoming 


higher  level  header. 
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1 .  Introduction 


One  of  the  mechanisms  of  IP  is  fragmentation  and  reassembly.  Under 
certain  circumstances,  a  datagram  originally  transmitted  as  a  single 
unit  will  arrive  at  its  final  destination  broken  into  several  fragments. 
The  IP  layer  at  the  receiving  host  must  accumulate  these  fragments  until 
enou^  have  arrived  to  completely  reconstitute  the  original  datagram. 
The  specification  document  for  IP  gives  a  complete  description  of  the 
reassembly  meclianism,  and  contains  several  examples.  It  also  provides 
one  possible  algorithm  for  reassembly,  based  on  keeping  track  of 
arriving  fragments  in  a  vector  of  bits.  This  document  describes  an 
alternate  approach  which  should  prove  more  suitable  in  some  machines. 


A  superficial  examination  of  the  reassembly  process  may  suggest 
that  it  is  rather  complicated.  First,  it  is  necessary  to  keep  track  of 
all  the  fragments,  which  suggests  a  small  bookkeeping  job.  Second,  when 
a  new  fragment  arrives,  it  may  combine  with  the  existing  fragments  in  a 
number  of  differenc  ways.  It  may  precisely  fill  the  space  between  two 
fragments,  or  it  may  overlap  with  existing  fragments,  or  conpletely 
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duplicate  existing  fragments,  or  partially  fill  a  ^ace  between  two 
fragments  without  abutting  either  of  them.  Thus,  it  might  seem  that  the 
reassembly  process  might  involve  designing  a  fairly  conplicated 
algorithm  that  tests  for  a  number  of  different  options. 

In  fact,  the  process  of  reassembly  is  extremely  simple.  This 
document  describes  a  way  of  dealing  with  reassembly  which  reduces  the 
bookkeeping  problem  to  a  minimum,  ^diich  requires  for  storage  only  one 
buffer  equal  in  size  to  the  final  datagram  being  reassembled,  which  can 
reassemble  a  datagram  from  any  number  of  fragments  arriving  in  any  order 
with  any  possible  pattern  of  overlap  and  duplication,  and  which  is 
appropriate  for  almost  any  sort  of  operating  system. 

The  reader  should  consult  the  IP  specification  document  to  be  sure 
that  he  is  completely  familiar  with  the  general  concept  of  reassembly, 
and  the  particular  header  fields  and  vocabulary  used  to  describe  the 
process . 


2.  The  Algorithm 

In  order  to  define  this  reassembly  algorithm,  it  is  necessary  to 
define  some  terms.  A  partially  reassembled  datagram  consists  of  certain 
sequences  of  octets  that  have  already  arrived,  and  certain  areas  still 
to  come.  We  will  refer  to  these  missing  areas  as  "holes".  Each  hole 
can  be  characterized  by  two  numbers,  hole,  first,  the  number  of  the  first 
octet  in  the  hole,  and  hole. last,  the  number  of  the  last  octet  in  the 
hole.  This  pair  of  numbers  we  will  call  the  "hole  descriptor",  and  we 
will  assume  that  all  of  the  hole  descriptors  for  a  particular  datagram 
are  gathered  together  in  the  "hole  descriptor  list" . 
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Ihe  general  form  of  the  algorithm  is  as  follows.  When  a  new 
fragment  of  the  datagram  arrives,  it  will  possibly  fill  in  one  or  more 
of  the  existing  holes.  We  will  examine  each  of  the  entries  in  the  hole 
descriptor  list  to  see  whether  the  hole  in  question  is  eliminated  by 
this  incoming  fragment.  If  so,  we  will  delete  that  entry  from  the  list. 
Eventually,  a  fragment  will  arrive  which  eliminates  every  entry  from  the 
list.  At  this  paint,  the  datagram  has  been  coispletely  reassembled  and 
can  be  passed  to  hi^er  protocol  levels  for  further  processing. 

Ihe  algorithm  will  be  described  in  two  {^ses.  In  the  first  part, 
we  will  show  the  sequence  of  steps  which  are  executed  when  a  new 
fragment  arrives,  in  order  to  determine  whether  or  not  any  of  the 
existing  holes  are  filled  by  the  new  fragment.  In  the  second  part  of 
this  description,  we  will  show  a  ridiculously  simple  algorithm  for 
management  of  the  hole  descriptor  list. 

3.  Fragment  Processing  Algorithm 

An  arriving  fragment  can  fill  any  of  the  existing  holes  in  a  number 
of  ways.  Most  simply,  it  can  conpletely  fill  a  hole.  Alternatively,  it 
may  leave  some  remaining  space  at  either  the  beginning  or  the  end  of  an 
existing  hole.  0/  finally,  it  can  lie  in  the  middle  of  an  existing 
hole,  breaking  the  hole  in  half  and  leaving  a  smaller  hole  at  each  end. 
Because  of  these  possibilities,  it  might  seem  that  a  number  of  tests 
must  be  made  when  a  new  fragment  arrives,  leading  tc  a  rather 
complicated  algorithm.  In  fact,  if  properly  e^ressed,  tije  algorithm 
can  compare  each  hole  to  the  arriving  fra^pent  in  only  four  tests. 
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We  start  the  algorithm  vhen  the  earliest  fragment  of  the  datagram 
arrives.  We  begin  by  creating  an  empty  data  buffer  area  and  putting  one 
entry  In  its  hole  descriptor  list,  the  entry  which  describes  the 
datagram  as  being  completely  missing.  In  this  case,  hole. first  equals 
zero,  and  hole. last  equals  Infinity.  (Infinity  is  presumably  inplemented 
by  a  very  large  Integer,  greater  than  576,  of  the  implementor's  choice.) 
The  following  eig^t  steps  are  then  used  to  Insert  each  of  the  arriving 
fragments  into  the  buffer  area  where  the  complete  datagram  is  being 
built  vp.  The  arriving  fragment  is  described  by  fragment,  first,  the 
first  octet  of  the  fragment,  and  fragment .  last,  the  last  octet  of  the 
fragment . 

1.  Select  the  next  hole  descriptor  from  the  hole  descriptor 
list.  If  there  are  no  more  entries,  go  to  step  eig^t. 

2.  If  fragment . first  is  greater  than  hole. last,  go  to  step  one. 

3.  If  fragment . last  is  less  than  hole. first,  go  to  step  one. 


h 


.  -4 


i 


(If  either  step  two  or  step  three  is  true,  then  the 
newly  arrived  fragment  does  not  overlap  with  the  hole  in 
any  way,  so  we  ne^  pay  no  further  attention  to  this 
hole.  We  return  to  the  beginning  of  the  algorithm  where 
ve  select  the  next  hole  for  examination.) 


4.  Delete  the  currcmit  cmitry  from  the  hole  descriptor  list. 


(Since  neither  step  two  nor  step  three  was  true,  the 
newly  arrived  fragment  does  interact  with  this  hole  in 
some  way.  Therefore,  the  current  descriptor  will  no 
longer  be  valid.  We  will  destroy  it,  and  in  the  next 
two  steps  we  will  determine  whether  or  not  it  is 
necessary  to  create  any  new  hole  descriptors.) 


E 


5.  If  fragment. first  is  greater  than  hole. first,  then  create  a 
new  hole  descriptor  "new^ole"  with  new^hole.  first  equal  to 

hole,  first,  and  new^ole.last  equal  to  fragaent .  first  minus  -[v 

one . 
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-  (If  the  test  in  st^  five  is  true,  then  the  first  part 
of  the  original  hole  is  not  filled  by  this  fragment.  We 
create  a  new  descriptor  for  this  smaller  hole.) 


6.  If  fragment .  last  is  less  than  hole,  last  and  fragment  .more 
fragoaents  is  true,  then  create  a  new  hole  descriptor 
''newjhole”,  with  new_hole .  first  equal  to  fragment. last  plus 
one  and  newjhole. last  equal  to  hole. last. 


(This  test  is  the  mirror  of  step  five  with  one 
additional  feature.  Initially,  we  did  not  know  how  long 
the  reassembled  datagram  would  be,  and  therefore  we 
created  a  hole  reaching  from  zero  to  infinity. 
Eventually,  we  will  receive  the  last  fragment  of  the 
datagram.  At  this  point,  that  hole  descriptor  which 
reaches  from  the  last  octet  of  the  buffer  to  infinity 
can  be  discarded.  The  fragment  which  contains  the  last 
fragment  indicates  this  fact  by  a  flag  in  the  internet 
header  called  "more  fragments".  The  test  of  this  bit  in 
this  statement  prevents  us  from  creating  a  descriptor 
for  the  unneeded  hole  which  describes  the  space  from  the 
end  of  the  datagram  to  infinity.) 


7.  Go  to  step  one. 

0.  If  the  hole  descriptor  list  is  now  enpty,  the  datagram  is  now 
complete.  Pass  it  on  to  the  hi9^er  level  protocol  processor 
for  further  handling.  Otherwise,  return. 


4.  Part  Two:  Managing  the  Hole  Descriptor  List 

The  main  conplexity  in  the  eight  step  algorithm  above  is  not 
performing  the  arithmetical  tests,  but  in  adding  and  deleting  witries 
from  the  hole  descriptor  list.  One  could  imagine  an  implementation  in 
\^ch  the  storage  management  package  was  many  times  more  conplicated 
than  the  rest  of  the  algorithm,  since  there  is  no  spxscifled  upper  limit 
on  the  number  of  hole  descriptors  which  will  exist  for  a  datagram  during 
reassembly.  There  is  a  very  siople  way  to  deal  with  the  hole 
descriptors,  however.  Just  put  each  hole  descriptor  in  the  first  octets 
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of  the  hole  Itself.  Note  that  by  the  definition  of  the  reassembly 
algorithm,  the  minimum  size  of  a  hole  is  eight  octets.  To  store 
hole,  first  and  hole. last  will  presumably  require  two  octets  each.  An 
additional  two  octets  will  be  required  to  thread  together  the  entries  on 
the  hole  descriptor  list.  This  leaves  at  least  two  more  octets  to  deal 
v/ith  implementation  idiosyncrasies. 

There  is  only  one  obvious  pitfall  to  this  storage  strategy.  One 
must  execute  the  eight  step  algorithm  above  before  copying  the  data  from 
the  fragment  into  the  reassembly  buffer.  If  one  were  to  copy  the  data 
first,  it  mi^^t  smash  one  or  more  hole  descriptors.  Once  the  algorithm 
above  has  been  run,  any  hole  descriptors  which  are  about  to  be  smashed 
have  already  been  rendered  obsolete. 

5 .  Loose  Ends 

Scattering  the  hole  descriptors  throughout  the  reassembly  buffer 
itself  requires  that  they  be  threaded  onto  some  sort  of  list  so  that 
they  can  be  found.  This  in  turn  implies  that  there  must  be  a  pointer  to 
the  head  of  the  list.  In  many  cases,  this  p>o inter  can  be  stored  in  some 
sort  of  descriptor  block  which  the  implementation  associates  with  each 
reassembly  buffer.  If  no  such  storage  is  available,  a  dirty  but 
effective  trick  is  to  store  the  head  of  the  list  in  a  part  of  the 
internet  header  in  the  reassembly  buffer  which  is  no  longer  needed.  An 
obvious  location  is  the  checksum  field. 

When  the  final  fragment  of  the  datagram  arrives,  the  packet  length 
field  in  the  internet  header  should  be  filled  in. 
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6 .  Options 

The  preceding  description  made  one  unacc^table  sinqplification.  It 
assumed  that  there  were  no  internet  options  associated  with  the  datagram 
being  reassembled.  The  difficulty  with  options  is  that  until  one 
receives  the  first  fragment  of  the  datagram,  one  cannot  tell  how  big  the 
internet  header  will  be.  This  is  because,  while  certain  options  are 
copied  identically  into  every  fragment  of  a  datagram,  other  options, 
sxich  as  "record  route",  are  put  in  the  first  fragment  only.  (The  "first 
fragment"  is  the  fragment  containing  octet  zero  of  the  original 
datagram.) 

Until  one  knows  how  big  the  internet  header  is,  one  does  not  know 
where  to  copy  the  data  from  each  fragment  into  the  reassembly  buffer. 
If  the  earliest  fragment  to  arrive  happens  to  bo  the  first  fragment, 
then  this  is  no  problem.  Otherwise,  there  are  two  solutions.  First, 
one  can  leave  space  in  the  reassembly  buffer  for  the  maximum  possible 
internet  header.  In  fact,  the  maximum  size  is  not  very  large,  64 
octets.  Alternatively,  one  can  simply  gamble  that  the  first  fragment 
will  contain  no  qptions.  If,  when  the  first  fragpncint  finally  arrives, 
there  are  options,  one  can  then  shift  the  data  in  the  buffer  a 
sufficient  distance  for  allow  for  them.  The  only  peril  in  copying  the 
data  is  that  one  will  trash  the  pointers  that  thread  the  hole 
descriptors  together.  It  is  easy  to  see  how  to  untrash  the  pointers. 


The  source  and  record  route  options  have  the  Interesting  feature 
that,  since  different  fragments  can  follow  different  paths,  they  may 
arrive  with  different  return  routes  recorded  in  different  fragments. 
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Normally,  this  is  more  information  than  the  receiving  Internet  module 
needs.  The  specified  procedure  is  to  take  the  return  route  recorded  in 
the  first  fragment  and  ignore  the  other  versions. 

7.  The  Complete  Algorithm 

In  addition  to  the  algorithm  described  above  there  are  two  parts  to 
tlie  reassembly  process.  First,  when  a  fragment  arrives,  it  is  necessary 
to  find  the  reassembly  buffer  associated  with  that  fragment.  This 
requires  some  mechanism  for  searching  all  the  existing  reassembly 
buffers.  The  correct  reassembly  buffer  is  identified  by  an  equality  of 
the  following  fields:  the  foreign  and  local  internet  address,  the 
protocol  ID,  and  the  identification  field. 

The  final  part  of  the  algorithm  is  some  sort  of  timer  based 
mechanism  which  decrements  the  time  to  live  field  of  each  partially 
reassembled  datagram,  so  that  incomplete  datagrams  which  have  outlived 
their  usefulness  can  be  detected  and  deleted.  One  can  either  create  a 
demon  which  comes  alive  once  a  second  and  decrements  the  field  in  each 
datagram  by  one,  or  one  can  read  the  clock  when  each  first  fragment 
arrives,  and  queue  some  sort  of  timer  call,  using  whatever  system 
mechanism  is  appropriate,  to  reap  the  datagram  when  its  time  has  come. 

An  inplementation  of  the  conplete  algorithm  comprising  all  these 
parts  was  constructed  in  BCPL  as  a  test.  The  conplete  algorithm  took 
less  than  one  and  one-half  pages  of  listing,  and  generated  approximately 
400  nova  machine  instructions.  That  portion  of  the  algorithm  actually 
Involved  with  management  of  hole  descriptors  is  about  20  lines  of  code. 


IMPLEMENTATION  GUIDELINES 


RFC  815 


9 

The  version  of  the  algorithm  described  here  is  actually  a 
sluplification  of  the  author's  original  version,  thanks  to  an  insightful 
observation  by  Elizabeth  Martin  at  MIT. 
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Introduction 


Occasionally,  a  network  or  a  gateway  will  go  down,  and  the  sequence 
of  hops  which  the  packet  takes  from  source  to  destination  must  change. 
Fault  Isolation  Is  that  action  which  hosts  and  gateways  collectively 
take  to  determine  that  something  Is  wrong;  fault  recovery  Is  the 
Identification  and  selection  of  an  altennatlve  route  which  will  serve  to 
reconnect  the  source  to  the  destination.  In  fact,  the  gateways  perform 
most  of  the  functions  of  fault  Isolation  and  recovery.  There  are, 
however,  a  few  actions  which  hosts  must  take  If  they  wish  to  provide  a 
reasonable  level  of  service.  This  document  describes  the  portion  of 
fault  Isolation  and  recovery  which  Is  the  responsibility  of  the  host. 


2.  What  Gateways  Do 


Gateways  collectively  implement  an  algorithm  which  identl  fies  the 
best  route  between  all  pairs  of  networks.  They  do  this  by  exchanging 
packets  which  contain  each  gateway's  latest  opinion  about  the 
operational  status  of  Its  neighbor  networks  and  gateways.  Assuming  that 
this  algorithm  is  operating  properly,  one  can  expect  the  gateways  to  go 
through  a  period  of  confusion  Immediately  after  some  network  or  gateway 
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has  failed,  but  one  can  assume  that  once  a  period  of  negotiation  has 
passed,  the  gateways  are  equipped  with  a  consistent  and  correct  model  of 
the  connectivity  of  the  internet.  At  present  this  period  of  negotiation 
may  actually  take  several  minutes,  and  many  TCP  implementations  time  out 
within  that  period,  but  it  is  a  design  goal  of  the  eventual  algorithm 
that  the  gateway  should  be  able  to  reconstruct  the  topology  quickly 
enough  that  a  TCP  connection  should  be  able  to  survive  a  failure  of  the 
route . 

3.  Host  Algorithm  for  Fault  Recovery 

Since  the  gateways  always  attenpt  to  have  a  consistent  and  correct 
model  of  the  internetwork  topology,  the  host  strategy  for  fault  recovery 
is  very  simple.  Whenever  the  host  feels  that  something  is  wrong,  it 
asks  the  gateway  for  advice,  and,  assuming  the  advice  is  forthcoming,  it 
believes  the  advice  completely.  The  advice  will  be  wrong  only  during 
the  transient  period  of  negotiation,  which  immediately  follows  an 
outage,  but  will  otherwise  be  reliably  correct. 

In  fact,  it  is  never  necessary  for  a  host  to  explicitly  ask  a 
gateway  for  advice,  because  the  gateway  will  provide  it  as  appropriate. 
When  a  host  sends  a  datagram  to  some  distant  net,  the  host  should  be 
prepared  to  receive  back  either  of  two  advisory  messages  which  the 
gateway  may  send.  The  ICMP  "redirect"  message  indicates  that  the 
gateway  to  which  the  host  sent  the  datagram  is  not  longer  the  best 
gateway  to  reach  the  net  in  question.  The  gateway  will  have  forwarded 
the  datagram,  but  the  host  should  revise  its  routing  table  to  have  a 
different  immediate  address  for  this  net.  The  ICMP  "destination 
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unreachable"  message  indicates  that  as  a  result  of  an  outage,  it  is 
currently  impossible  to  reach  the  addressed  net  or  host  in  any  mzinner. 
On  receipt  of  this  message,  a  host  can  either  abandon  the  connection 
immediately  without  any  further  retransmission,  or  resend  slowly  to  see 
if  tlie  fault  is  corrected  in  reasonable  time. 

If  a  host  could  assume  that  these  two  ICMP  messages  would  always 
arrive  \^en  something  was  amiss  in  the  network,  then  no  other  action  on 
the  part  of  the  host  would  be  required  in  order  maintain  its  tables  in 
an  optimal  condition.  Unfortunately,  there  are  two  circumstances  under 
which  the  messages  will  not  arrive  properly.  First,  during  the 
transient  following  a  failure,  error  messages  may  arrive  that  do  not 
correctly  represent  the  state  of  the  world.  Ihus,  hosts  must  take  an 
isolated  error  message  with  some  scepticism.  (Ihis  transient  period  is 
discussed  more  fully  below.)  Second,  if  the  host  has  been  sending 
datagrams  to  a  particular  gateway,  and  that  gateway  itself  crashes,  then 
all  the  other  gateways  in  the  internet  will  reconstruct  the  topology, 
but  the  gateway  in  question  will  still  be  down,  and  therefore  cannot 
provide  any  advice  back  to  the  host.  As  long  as  the  host  continues  to 
direct  datagrams  at  this  dead  gateway,  the  datagrams  will  simply  vanish 
off  the  face  of  the  earth,  and  nothing  will  come  back  in  return.  Hosts 
must  detect  this  failure. 

If  some  gateway  many  hops  away  fails,  this  is  not  of  concern  to  the 
host,  for  then  the  discovery  of  the  failure  is  the  responsibility  of  the 
Immediate  neigfibor  gateways,  which  will  perform  this  action  in  a  manner 
invisible  to  the  host.  The  problem  only  arises  if  the  very  first 
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gateway,  the  one  to  which  the  host  is  immediately  sending  the  datagrams, 
fails.  We  thus  identify  one  single  task  which  the  host  must  perform  as 
its  part  of  fault  isolation  in  the  internet:  the  host  must  use  some 
strategy  to  detect  that  a  gateway  to  which  it  is  sending  datagrams  is 

dead. 

Let  us  assume  for  the  moment  that  the  host  implements  some 
algorithm  to  detect  failed  gateways;  we  will  return  later  to  discuss 
what  this  algorithm  might  be.  First,  let  us  consider  what  the  host 
should  do  when  it  has  determined  that  a  gateway  is  down.  In  fact,  with 
the  exertion  of  one  small  problem,  the  action  the  host  should  take  is 
extremely  simple.  'Ihe  host  should  select  some  other  gateway,  and  try 
sending  the  datagram  to  it.  Assuming  that  gateway  is  up,  this  will 
either  produce  correct  results,  or  some  ICMP  advice.  Since  we  assume 
that,  ignoring  temporary  periods  immediately  following  an  outage,  any 
gateway  is  capable  of  giving  correct  advice,  once  the  host  has  received 
advice  from  any  gateway,  that  host  is  in  as  gov>d  a  condition  as  it  can 
hope  to  be. 

There  is  always  the  unpleasant  possibility  that  vhen  the  host  tries 
a  different  gateway,  that  gateway  too  will  be  down.  Therefore,  whatever 
algorithm  the  host  uses  to  detect  a  dead  gateway  must  continuously  be 
applied,  as  the  host  tries  every  gateway  in  turn  that  it  knows  about. 

The  only  difficult  part  of  this  algorithm  is  to  specify  the  means 
by  which  the  host  maintains  the  table  of  all  of  the  gateways  to  which  it 
has  immediate  access.  Currently,  the  spjecification  of  the  internet 
protocol  does  not  architect  any  message  by  which  a  host  can  ask  to  be 
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supplied  with  such  a  table.  The  reason  is  that  different  networks  may 
provide  very  different  mechanisms  by  which  this  table  can  be  filled  in. 
For  exanple,  if  the  net  is  a  broadcast  net,  such  as  an  ethemet  or  a 
ringnet,  every  gateway  may  sinply  broadcast  such  a  table  from  time  to 
time,  and  the  host  need  do  nothing  but  listen  to  obtain  the  required 
information.  Alternatively,  the  network  may  provide  the  mechanism  of 
logical  addressing,  by  which  a  whole  set  of  machines  can  be  provided 
with  a  single  group  address,  to  which  a  request  can  be  sent  for 
assistance.  Failing  those  two  schemes,  the  host  can  build  up  its  table 
of  neig^or  gateways  by  remernbering  all  the  gateways  from  which  it  has 
ever  received  a  message.  Finally,  in  certain  cases,  it  may  be  necessary 
for  this  table,  or  at  least  the  initial  entries  in  the  table,  to  be 
constructed  manually  by  a  manager  or  operator  at  the  site.  In  cases 
where  the  network  in  question  provides  absolutely  no  support  for  this 
kind  of  host  query,  at  least  some  manual  intervention  will  be  required 
to  get  started,  so  that  the  host  can  find  out  about  at  least  one 
gateway . 


4.  Host  Algorithms  for  Fault  Isolation 


We  now  return  to  the  question  raised  above.  What  strategy  should 
the  host  use  to  detect  that  it  is  talking  to  a  dead  gateway,  so  that  it 
can  know  to  switch  to  some  other  gateway  in  the  list.  In  fact,  there  are 
several  algorithms  which  can  be  used.  All  are  reasonably  sinple  to 
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1.  NETWORK  LEVEL  DETECTION 

Many  networks,  particularly  the  Arpanet,  perform  precisely  the 
required  function  internal  to  the  network.  If  a  host  sends  a  datagram 
to  a  dead  gateway  on  the  Arpanet,  the  network  will  return  a  "host  dead" 
mefjsage,  which  is  precisely  the  information  the  host  needs  to  know  in 
order  to  switch  to  another  gateway.  Some  early  implementations  of 
Internet  on  the  Arpanet  threw  these  messages  away.  That  is  an 
exceedingly  poor  idea. 

2.  CONTINUOUS  POLLING 

The  ICMP  protocol  provides  an  echo  mechanism  by  which  a  host  may 
solicit  a  response  from  a  gateway.  A  host  could  simply  send  this 
message  at  a  reasonable  rate,  to  assure  itself  continuously  that  the 
gateway  was  still  vp.  This  works,  but,  since  the  message  must  be  sent 
fairly  often  to  detect  a  fault  in  a  reasonable  time,  it  can  imply  an 
unbearable  overhead  on  the  host  Itself,  the  network,  and  tlie  gateway. 
This  strategy  is  prohibited  except  vhere  a  specific  analysis  has 
indicated  that  the  overhead  is  tolerable. 

3.  TRIGGERED  POLLING 

If  the  use  of  polling  could  be  restricted  to  only  those  times  when 
something  seemed  to  be  wrong,  then  che  overhead  would  be  bearable. 
Provided  that  one  can  get  the  proper  advice  from  one's  higher  level 
protocols,  it  is  possible  to  implenent  such  a  strategy.  For  exanple, 
one  could  program  the  TCP  level  so  that  whenever  it  retransmitted  a 
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segment  more  than  once,  it  sent  a  hint  down  to  the  IP  layer  which 
triggered  polling.  This  strategy  does  not  have  excessive  overhead,  but 
does  have  the  problan  that  the  host  may  be  somewhat  slow  to  respond  to 
an  error,  since  only  after  polling  has  started  will  the  host  be  able  to 
confirm  that  something  has  gone  wrong,  and  by  then  the  TCP  above  may 
have  already  timed  out. 

Both  forms  of  polling  suffer  from  a  minor  flaw.  Hosts  as  well  as 
gateways  respond  to  ICMP  echo  messages.  Thus,  polling  cannot  be  used  to 
detect  the  error  that  a  foreign  address  thou^t  to  be  a  gateway  is 
actually  a  host.  Such  a  confusion  can  arise  if  the  physical  addresses 
of  machines  are  rearranged. 

4.  TRIGGERED  RESELECTION 

There  is  a  strategy  which  makes  use  of  a  hint  from  a  hig^ber  level, 
as  did  the  previous  strategy,  but  which  avoids  polling  altogether. 
Whenever  a  higher  level  complains  that  the  service  seems  to  be 
defective,  the  Internet  layer  can  pick  the  next  gateway  from  the  list  of 
available  gateways,  and  switch  to  it.  Assuming  that  this  gateway  is  up, 
no  real  harm  can  come  of  this  decision,  even  if  it  was  wrong,  for  the 
worst  that  will  happen  is  a  redirect  message  which  Instructs  the  host  to 
return  to  the  gateway  originally  being  used.  If,  on  the  other  hand,  the 
original  gateway  was  Indeed  down,  then  this  immediately  provides  a  new 
route,  so  the  period  of  time  until  recovery  is  shortened.  This  last 
strategy  seems  particularly  clever,  and  is  probably  the  most  generally 
suitable  for  those  cases  where  the  network  Itself  does  not  provide  fault 
isolation.  (Regretably',  I  have  forgotten  who  suggested  this  idea  to  me. 
It  is  not  my  invention.) 
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5.  Higher  Level  Fault  Detection 

The  previous  discussion  has  concentrated  on  fault  detection  and 
recovery  at  the  IP  layer.  This  section  considers  what  the  hl^^ier  layers 
such  as  TCP  should  do. 

TCP  has  a  single  fault  recovery  action;  it  repeatedly  retransmits  a 
segment  until  either  It  gets  an  acknowledgement  or  its  connection  timer 
expires.  As  discussed  above «  It  may  use  retransmission  as  an  event  to 
trigger  a  request  for  fault  recovery  to  the  IP  layer.  In  the  other 
direction.  Information  may  flow  from  IP,  reporting  such  things  as 
ICMP  Destination  Unreachable  or  error  messages  from  the  attached 
network.  The  only  subtle  question  about  TCP  and  faults  Is  what  TCP 
should  do  when  such  an  error  message  arrives  or  Its  connection  timer 
e^lres . 

The  TCP  specification  discusses  the  timer.  In  the  description  of 
the  open  call,  the  timeout  is  described  as  an  optional  value  that  the 
client  of  TCP  may  specify*  if  any  segment  remains  unacknowledged  for 
this  period,  TCP  should  abort  the  connection.  The  default  for  the 
timeout  is  30  seconds.  Early  TCPs  were  often  Implemented  with  a  fixed 
timeout  Interval,  but  this  did  not  work  well  in  practice,  as  the 
following  discussion  may  suggest. 

Clients  of  TCP  can  be  divided  into  two  classes:  those  ruiinlng  on 
immediate  behalf  of  a  human,  such  as  Telnet,  and  those  supporting  a 
program,  such  as  a  mail  sender.  I&imans  require  a  sophisticated  response 
to  errors.  D^>endlng  on  exactly  what  went  wrong,  they  may  want  to 
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abandon  the  connection  at  once,  or  wait  for  a  long  time  to  see  if  things 
get  better.  Programs  do  not  have  this  human  impatience,  but  also  lack 
the  power  to  make  conplex  decisions  based  on  details  of  the  exact  error 
condition.  For  them,  a  simple  timeout  is  reasonable. 


S 


m 


>v 
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Based  on  these  considerations,  at  least  two  modes  of  operation  are 
needed  in  TCP.  One,  for  programs,  abandons  the  connection  without 
I  exception  if  the  TCP  timer  e3g)ires.  The  other  mode,  suitable  for 

peqple,  never  abandons  the  connection  on  its  own  initiative,  but  rqports 
to  the  layer  above  when  the  timer  expires.  Thus,  the  human  user  can  see 
j  error  messages  coming  from  all  the  relevant  layers,  TCP  and  ICMP,  and 

can  request  TCP  to  abort  as  appropriate.  This  second  mode  requires  that 
TCP  be  able  to  send  an  asynchronous  message  up  to  its  client  to  report 
the  timeout,  and  it  requires  that  error  messages  arriving  at  lower 
layers  similarly  flow  up  through  TCP. 

1  At  levels  above  TCP,  fault  detection  is  also  required.  Either  of 

« 

I  the  following  can  happen.  First,  the  foreign  client  of  TCP  can  fail, 

j  even  though  TCP  is  still  running,  so  data  is  still  acknowledged  and  the 

timer  never  esqsires.  Alternatively,  the  communication  path  can  fall, 
without  the  TCP  timer  going  off,  because  the  local  client  has  no  data  to 
send.  Both  of  these  have  caused  trouble. 

Sending  mail  provides  an  example  of  the  first  case.  When  sending 
mail  using  SMTP,  there  is  an  SMTP  level  acknowledgement  that  is  returned 
when  a  piece  of  mail  is  successfully  delivered.  Several  early  mall 


i 


receiving  programs  would  crash  just  at  the  point  where  they  had  received 
all  of  the  mall  text  (so  TCP  did  not  detect  a  timeout  due  to  outstanding 


unacknowledged  data)  but  before  the  mail  was  acknowledged  at  the  SMTP 
level.  This  failure  would  cause  early  mail  senders  to  wait  forever  for 
the  SMTP  level  acknowledgement.  The  obvious  cure  was  to  set  a  timer  at 
the  SMTP  level,  but  the  first  attenpt  to  do  this  did  not  work,  for  there 
wac  no  sinple  way  to  select  the  timer  interval.  If  the  interval 
selected  was  short,  it  ejqpired  in  normal  operational  when  sending  a 
large  file  to  a  slow  host.  An  interval  of  many  minutes  was  needed  to 
prevent  false  timeouts,  but  that  meant  that  failures  were  detected  only 
very  slowly.  The  current  solution  in  several  mailers  is  to  pick  a 
timeout  interval  proportional  to  the  size  of  the  message. 

Server  telnet  provides  an  example  of  the  other  kind  of  failure.  It 
can  easily  happen  that  the  communications  link  can  fail  while  there  is 
no  traffic  flowing,  p>erhaps  because  the  user  is  thinking.  Eventually, 
the  user  will  attempt  to  type  something,  at  which  time  he  will  discover 
that  the  connection  is  dead  and  abort  it.  But  the  host  end  of  the 
connection,  having  nothing  to  send,  will  not  discover  anything  wrong, 
and  will  remain  waiting  forever.  In  some  systems  there  is  no  way  for  a 
user  in  a  different  process  to  destroy  or  take  over  such  a  hanging 
process,  so  there  is  no  way  to  recover. 

One  solution  to  this  would  be  to  have  the  host  server  telnet  query 
the  user  end  now  and  then,  to  see  if  it  is  still  up.  (Telnet  does  not 
have  an  explicit  query  feature,  but  the  host  could  negotiate  some 
uninportant  option,  which  should  produce  either  agreement  or 
disagreement  in  return.)  The  only  problem  with  this  is  that  a 
reasonable  saztple  interval,  if  applied  to  every  user  on  a  large  system. 


can  generate  an  unacceptable  amount  of  traffic  and  system  overhead.  A 
smart  server  telnet  would  use  this  query  only  when  something  seems 
wrong,  perhaps  when  there  had  been  no  user  activity  for  some  time. 

In  b  ‘-h  these  cases,  the  general  conclusion  is  tliat  client  level 
error  detection  is  needed,  and  that  the  details  of  the  mechanism  are 
very  dependent  on  the  application.  Application  programmers  must  be  made 
aware  of  the  problem  of  failures,  and  must  understand  that  error 
detection  at  the  TCP  or  lower  level  cannot  solve  the  whole  problem  for 
them. 

6.  Knowing  When  to  Give  Up 

It  is  not  obvious,  when  error  messages  such  as  ICMP  Destination 
Unreachable  arrive,  whether  TCP  should  abandon  the  connection.  The 
reason  that  error  messages  are  difficult  to  interpret  is  that,  as 
discussed  above,  after  a  failure  of  a  gateway  or  network,  there  is  a 
transient  period  during  which  the  gateways  may  have  incorrect 
information,  so  that  irrelevant  or  incorrect  error  messages  may 
sometimes  return.  An  isolated  ICMP  Destination  Unreachable  may  arrive 
at  a  host,  for  example,  if  a  packet  is  sent  during  the  period  when  the 
gateways  are  trying  to  find  a  new  route.  To  abandon  a  TCP  connection 
based  on  such  a  message  arriving  would  be  to  ignore  the  valuable  feature 
of  the  Internet  that  for  many  internal  failures  it  reconstructs  its 
function  without  any  disruption  of  the  end  points. 

But  if  failure  messages  do  not  inply  a  failure,  what  are  they  for? 
In  fact,  error  messages  serve  several  inportant  purposes.  First,  if 
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1 .  Introduction 

Many  protocol  inplementers  have  made  the  unpleasant  discovery  that 
their  packages  do  not  run  quite  as  fast  as  they  had  hoped.  The  blame 
for  this  widely  observed  problem  has  been  attributed  to  a  variety  of 
causes,  ranging  from  details  in  the  design  of  the  protocol  to  the 
underlying  structure  of  the  host  operating  system.  This  RFC  will 
discuss  some  of  the  commonly  encountered  reasons  why  protocol 
inplementations  seem  to  run  slowly. 

Ebqserience  suggests  that  one  of  the  most  inportant  factors  in 
determining  the  performance  of  an  implementation  is  the  manner  in  which 
that  implementation  is  modularized  and  integrated  into  the  host 
operating  system.  For  this  reason,  it  is  useful  to  discuss  the  question 
of  how  an  inplementation  is  structured  at  the  same  time  that  we  consider 
how  it  will  perform.  In  fact,  this  RFC  will  argue  that  modularity  is 
one  of  the  chief  villains  in  attempting  to  obtain  good  performance,  so 
that  the  designer  is  faced  with  a  delicate  and  inevitable  tradeoff 
between  good  structure  and  good  performance.  Further,  the  single  factor 
which  most  strongly  determines  how  well  this  conflict  can  be  resolved  is 
not  the  protocol  but  the  operating  system. 
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7.  Efficiency  Considerations 


There  are  many  aspects  to  efficiency.  One  aspect  is  sending  data 
at  minimum  transmission  cost,  which  is  a  critical  aspect  of  common 
carrier  communications,  if  not  in  local  area  network  communications. 
Another  aspect  is  sending  data  at  a  high  rate,  which  may  not  be  possible 
at  all  if  the  net  is  very  slow,  but  which  may  be  the  one  central  design 
constraint  when  taking  advantage  of  a  local  net  with  hi^  raw  bandwidth. 
The  final  consideration  is  doing  the  above  with  minimum  expenditure  of 
conputer  resources.  This  last  may  be  necessary  to  achieve  high  speed, 
but  in  the  case  of  the  slow  net  may  be  inqportant  only  in  that  the 
resources  used  up,  for  exanple  cpu  cycles,  are  costly  or  otherwise 
needed.  It  is  worth  pointing  out  that  these  different  goals  often 
conflict;  for  example  it  is  often  possible  to  trade  off  efficient  use  of 
the  computer  against  efficient  use  of  the  network.  Thus,  there  may  be 
no  such  thing  as  a  successful  general  purpose  protocol  implementation. 

The  simplest  measure  of  performance  is  throughput,  measured  in  bits 
per  second.  It  is  worth  doing  a  few  simple  conputations  in  order  to  get 
a  feeling  for  the  magnitude  of  the  problems  involved.  Assume  that  data 
is  being  sent  from  one  machine  to  another  in  packets  of  576  bytes,  the 
maximum  generally  acc^table  internet  packet  size.  Allowing  for  header 
overhead,  this  packet  size  permits  4288  bits  in  each  packet.  If  a 
useful  throughput  of  10,000  bits  per  second  is  desired,  then  a  data 
bearing  packet  must  leave  the  sending  host  about  every  430  milliseconds, 
a  little  over  two  per  second.  This  is  clearly  not  difficult  to  achieve. 
However,  if  one  wishes  to  achieve  100  kilobits  per  second  throughput. 
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the  packet  must  leave  the  host  every  43  milliseconds,  and  to  achieve  one 
megabit  per  second,  which  is  not  at  all  unreasonable  on  a  high-speed 
local  net,  the  packets  must  be  spaced  no  more  than  4.3  milliseconds. 

ITiese  latter  numbers  are  a  slightly  more  alarming  goal  for  which  to 
set  one's  sights.  Many  operating  systems  take  a  substantial  fraction  of 
a  millisecond  just  to  service  an  interrupt.  If  the  protocol  has  been 
structured  as  a  process,  it  is  necessary  to  go  through  a  process 
scheduling  before  the  protocol  code  can  even  begin  to  run.  If  any  piece 
of  a  protocol  package  or  its  data  must  be  fetched  from  disk,  real  time 
delays  of  between  30  to  100  milliseconds  can  be  expected.  If  the 
protocol  must  compete  for  cpu  resources  with  other  processes  of  the 
system,  it  may  be  necessary  to  wait  a  scheduling  quantum  before  the 
protocol  can  run.  Many  systems  have  a  scheduling  quantum  of  100 
milliseconds  or  more.  Considering  these  sorts  of  numbers,  it  becomes 
immediately  clear  that  the  protocol  must  be  fitted  into  the  operating 
system  in  a  thorough  and  effective  manner  if  any  like  reasonable 
throuc(hput  is  to  be  achieved. 

There  is  one  obvious  conclusion  immediately  suggested  by  even  this 
sinple  analysis.  Except  in  very  sjjecial  circumstances,  when  many 
packets  are  being  processed  at  once,  the  cost  of  processing  a  packet  is 
dominated  by  factors,  such  as  cpu  scheduling,  which  are  independent  of 
the  packet  size.  This  suggests  two  general  rules  which  any 
implementation  ougiht  to  obey.  First,  send  data  in  large  packets. 
Obviously,  if  processing  time  per  packet  is  a  constant,  then  throug^ut 
will  be  directly  proportional  to  the  packet  size.  Second,  never  send  an 
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unneeded  packet.  Unneeded  packets  use  up  just  as  many  resources  as  a 
packet  full  of  data,  but  perform  no  useful  function.  RFC  813,  "Window 
and  Acknowledgement  Strategy  in  TCP",  discusses  one  aspect  of  reducing 
the  number  of  packets  sent  per  useful  data  byte.  This  document  will 
mention  other  attacks  on  the  same  problem. 

The  above  analysis  suggests  that  there  are  two  main  parts  to  the 
problem  of  achieving  good  protocol  performance.  The  first  has  to  do 
with  how  the  protocol  inplementation  is  integrated  into  the  host 
operating  system.  The  second  has  to  do  with  how  the  protocol  package 
itself  is  organized  internally.  This  document  will  consider  each  of 
these  topics  in  turn. 

3.  The  Protocol  vs.  the  Operating  System 

There  are  normally  three  reasonable  ways  in  which  to  add  a  protocol 
to  an  operating  system.  The  protocol  can  be  in  a  process  that  is 
provided  by  the  operating  system,  or  it  can  be  part  of  the  kernel  of  the 
operating  system  itself,  or  it  can  be  put  in  a  separate  communications 
processor  or  front  end  machine.  This  decision  is  strongly  influencvKi  by 
details  of  hardware  architecture  and  op>erating  system  design;  each  of 
these  three  approaches  has  its  own  advantages  and  disadvantages. 

The  "process"  is  the  abstraction  which  most  operating  systems  use 
to  provide  the  execution  environment  for  user  programs,  A  very  simple 
path  for  implementing  a  protocol  is  to  obtain  a  process  from  the 
operating  system  and  implement  the  protocol  to  run  in  it. 
SL5>erfici£Lly,  this  approach  has  a  number  of  advantages.  Since 
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modifications  to  the  kernel  are  not  required,  the  Job  can  be  done  by 
someone  who  is  not  an  expert  in  the  kernel  structure.  Since  it  is  often 
inpossible  to  find  somebody  who  is  esqperj-enced  both  in  the  structure  of 
the  operating  system  and  the  structure  of  the  protocol,  this  path,  from 
a  management  point  of  view,  is  often  extremely  appealing.  Unfortunately, 
putting  a  protocol  in  a  process  has  a  number  of  disadvantages,  related 
to  both  structure  and  performance.  First,  as  was  discussed  above, 
process  scheduling  can  be  a  significant  source  of  real-time  delay. 
There  is  not  only  the  actual  cost  of  going  through  the  scheduler,  but 
the  problem  that  the  operating  system  may  not  have  the  right  sort  of 
priority  tools  to  bring  the  process  into  execution  quickly  whenever 
there  is  work  to  be  done. 

Structurally,  the  difficulty  with  putting  a  protocol  in  a  process 
is  that  the  protocol  may  be  providing  services,  for  example  support  of 
data  streams,  which  are  normally  obtained  by  going  to  special  kernel 
entry  points.  Depending  on  the  generality  of  the  operating  system,  it 
may  be  inpossible  to  take  a  program  which  is  accustomed  to  reading 
through  a  ker:*el  encry  point,  and  redirect  it  so  it  is  reading  the  data 
from  a  process.  The  most  extreme  exanple  of  this  problem  occurs  when 
inplementing  server  telnet.  In  almost  all  systems,  the  device  handler 
for  the  locally  attached  teletypes  is  located  inside  the  kernel,  and 
programs  read  and  write  from  their  teletype  by  making  kernel  calls.  If 
server  telnet  is  Inplemented  in  a  process,  it  is  then  necessary  to  take 
the  data  streams  provided  by  server  telnet  and  somehow  get  them  back 
down  inside  the  kernel  so  that  they  mimic  the  interface  provided  by 
local  teletypes.  It  is  usually  the  case  that  special  kernel 
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modification  is  necessary'  to  achieve  this  structure,  which  somewhat 
defeats  the  benefit  of  having  removed  the  protocol  from  the  kernel  in 
the  first  place. 

Clearly,  then,  there  are  advantages  to  putting  the  protocol  package 
in  the  kernel .  Structurally,  it  is  reasonable  to  view  the  network  as  a 
device,  and  device  drivers  are  traditionally  contained  in  the  kernel. 
Presumably,  the  problems  associated  with  process  scheduling  can  be 
sidest^:>ed,  at  least  to  a  certain  extent,  by  placing  the  code  inside  the 
kernel .  And  it  is  obviously  easier  to  make  the  server  telnet  channels 
mimic  the  local  teletype  channels  if  they  are  both  realized  in  the  same 
level  in  the  kernel . 

However,  inplementation  of  protocols  in  the  kernel  has  its  own  set 
of  pitfalls.  First,  network  protocols  have  a  characteristic  which  is 
shared  by  almost  no  other  device:  they  require  rather  complex  actions 
to  be  performed  as  a  result  of  a  timeout.  The  problem  with  this 
requirement  is  that  the  kernel  often  has  no  facility  by  which  a  program 
can  be  brought  into  execution  as  a  result  of  the  timer  event.  What  is 
really  needed,  of  course,  is  a  special  sort  of  process  inside  the 
kernel.  Most  systems  lack  this  mechanism.  Failing  that,  the  only 
execution  mechanism  available  is  to  run  at  interrupt  time. 

There  are  substantial  drawbacks  to  inplementing  a  protocol  to  run 
at  Interrupt  time.  First,  the  actions  p>er formed  may  be  somewhat  complex 
and  time  consuming,  compared  to  the  mcixiroum  amount  of  time  that  the 
opjerating  system  is  prepared  to  spend  servicing  an  interrupt.  Problems 
can  arise  if  interrupts  are  masked  for  too  long.  This  is  particularly 
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bad  when  running  as  a  result  of  a  clock  interrupt,  which  can  inply  that 
the  clock  interrupt  is  masked.  Second,  the  environment  provided  by  an 
interrupt  handler  is  usually  extremely  primitive  conpared  to  the 
environment  of  a  process.  There  are  usually  a  variety  of  system 
facilities  which  are  unavailable  while  running  in  an  interrupt  handler. 
The  most  important  of  these  is  the  ability  to  suspend  execution  pending 
the  arrival  of  some  event  or  message.  It  is  a  cardinal  rule  of  almost 
every  known  operating  system  that  one  must  not  invoke  the  scheduler 
while  running  in  an  interrupt  handler.  Thus,  the  programmer  who  is 
forced  to  implement  all  or  part  of  his  protocol  package  as  an  interrupt 
handler  must  be  the  best  sort  of  e^qpert  in  the  operating  system 
involved,  and  must  be  prepared  for  development  sessions  filled  with 
obscure  bugs  which  crash  not  just  the  protocol  package  but  the  entire 
operating  system. 

A  final  problem  with  processing  at  interrupt  time  is  that  the 
system  scheduler  has  no  control  over  the  percentage  of  system  time  used 
by  the  protocol  handler.  If  a  large  number  of  packets  arrive,  from  a 
foreign  host  that  is  either  malfunctioning  or  fast,  all  of  the  time  may 
be  spent  in  the  interrupt  handler,  effectively  killing  the  system. 

There  are  other  problems  associated  with  putting  protocols  into  an 
operating  system  kernel .  The  simplest  problem  often  encountered  is  that 
the  kernel  address  space  is  simply  too  small  to  hold  the  piece  of  code 
in  question.  This  is  a  rather  artificial  sort  of  problem,  but  it  is  a 
severe  problem  none  the  less  in  many  machines.  It  is  an  appallingly 
unpleasant  exjperience  to  do  an  implementation  with  the  knowledge  that 


DDN  PROTOCOL  HANDBOOK  -  VOLUlvIE  THREE 


1985 


for  every  byte  of  new  feature  put  in  one  must  find  some  other  byte  of 
old  feature  to  throw  out.  It  is  hopeless  to  expect  an  effective  and 
general  implementation  under  this  kind  of  constraint.  Another  problem 
is  that  the  protocol  package^  once  it  is  thorouc^ly  entwined  in  the 
operating  system,  may  need  to  be  reidone  every  time  the  operating  syston 
changes.  If  the  protocol  and  the  operating  systetin  are  not  maintained  by 
the  same  group,  this  makes  maintenance  of  the  protocol  package  a 
perpetual  headache. 

The  third  option  for  protocol  iiipleme:.tation  is  to  take  the 
protocol  package  and  move  it  outside  the  uachine  entirely,  on  to  a 
separate  processor  dedicated  to  this  kind  of  task.  Such  a  machine  is 
often  described  as  a  communications  processor  or  a  front-end  processor. 
There  are  several  advantages  to  tnis  approach.  First,  the  operating 
system  on  the  communications  processor  can  be  tailored  for  precisely 
this  kind  of  task.  This  msikes  tho  job  of  inplementation  much  easier. 
Second,  one  does  not  need  to  redo  the  task  for  every  machine  to  which 
the  protocol  is  to  be  added.  It  may  be  possible  to  reuse  the  same 
front-end  machine  on  different  host  conputers.  Since  the  task  need  not 
be  done  as  many  times,  one  might  hops  that  more  attention  could  be  paid 
to  doing  it  rl^t.  Given  a  careful  implementation  in  an  environment 
which  is  optimized  for  this  kind  of  task,  the  resulting  package  should 
turn  out  to  be  very  efficient.  Unfortunately,  there  are  also  problems 
with  this  approach.  There  is,  of  course,  a  financial  problem  associated 
with  buying  an  additional  coaputer.  In  many  cases,  this  is  not  a 
problem*  at  all  since  the  cost  is  negligible  compared  to  what  the 
programmer  would  cost  to  do  the  job  in  the  mainframe  Itself.  More 
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fundamentally,  the  communications  processor  approach  does  not  conpletely 
sidestep  any  of  the  problems  raised  above.  The  reason  is  that  the 
communications  processor,  since  it  is  a  separate  machine,  must  be 
attached  to  the  mainframe  by  some  mechanism.  Whatever  that  mechanism, 
code  is  required  in  the  mainframe  to  deal  with  it.  It  can  be  argued 
that  the  program  to  deal  with  the  communications  processor  is  siirpler 
than  the  program  to  inplement  the  entire  protocol  package.  Even  if  that 
is  so,  the  communications  processor  interface  package  is  still  a 
protocol  in  nature,  with  all  of  the  same  structural  problems.  Thus,  all 
of  the  issues  raised  above  must  still  bo  faced.  In  addition  to  those 
problems,  there  are  some  other,  more  subtle  problems  associated  with  an 
outboard  inplementation  of  a  protocol.  We  will  return  to  these  problems 
later . 

There  is  a  way  of  attaching  a  communications  processor  to  a 
mainframe  host  which  sidesteps  all  of  the  mainframe  Inplementation 
problems,  which  is  to  use  some  preexisting  interface  on  the  host  machine 
as  the  port  by  which  a  communications  processor  is  attached.  This 
strategy  is  often  used  as  a  last  stage  of  desperation  when  the  software 
on  the  host  conputer  is  so  intractable  that  it  cannot  be  changed  in  any 
way.  Unfortunately,  it  is  almost  inevitabl'^'  the  case  that  all  of  the 
available  interfaces  are  totally  unsuitable  for  this  purpose,  so  the 
result  is  unsatisfactory  at  best.  The  most  common  way  in  which  this 
form  of  attachment  occurs  is  when  a  network  conncsctlon  is  being  used  to 
mimic  local  teletypes.  In  this  case,  the  frcnt-end  processor  can  be 
attached  to  the  mainframe  by  sinply  providing  a  number  of  wires  out  of 
tile  front-end  processor,  each  corresponding  to  a  connection,  which  are 
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plugged  into  teletype  ports  on  the  mainframe  computer.  (Because  of  the 
appearance  of  the  physical  configuration  which  results  from  this 
arrangement,  Michael  Padlipsky  has  described  this  as  the  "milking 
machine"  approach  to  computer  networking.)  This  strategy  solves  the 
immediate  problem  of  providing  remote  access  to  a  host,  but  it  is 
extremely  inflexible.  The  channels  being  provided  to  the  host  are 
restricted  by  the  host  software  to  one  purpose  only,  remote  login.  It 
is  inpossible  to  use  them  for  any  other  purpose,  such  as  file  transfer 
or  sending  mail,  so  the  host  is  integrated  into  the  network  envj.ronment 
in  an  extremely  limited  and  inflexible  manner.  If  this  is  the  best  that 
can  be  done,  then  it  should  be  tolerated.  Otherwise,  implementors 
should  be  strongly  encouraged  to  take  a  more  flexible  approach. 

4 .  Protocol  Layering 

The  previous  discussion  suggested  that  there  was  a  decision  to  be 
made  as  to  where  a  protocol  ou^t  to  be  implemented.  In  fact,  the 
decision  is  much  more  complicated  than  that,  for  the  goal  is  not  to 
implement  a  single  protocol,  but  to  implement  a  whole  family  of  protocol 
layers,  starting  with  a  device  driver  or  local  network  driver  at  the 
bottom,  then  IP  and  TCP,  and  eventually  reaching  the  application 
specific  protocol,  such  as  Telnet,  FTP  and  SMTP  on  the  top.  Clearly, 
the  bottommost  of  these  layers  is  somewhere  within  the  kernel,  since  the 
physical  device  driver  for  the  net  is  almost  inevitably  located  there. 
Equally  clearly,  the  top  layers  of  this  package,  which  provide  the  user 
his  ability  to  perform  the  remote  login  function  or  to  send  mail,  are 
not  entirely  contained  within  the  kernel.  Thus,  the  question  is  not 


whether  the  protocol  family  shall  be  inside  or  outside  the  kernel,  but 
how  it  shall  be  sliced  in  two  between  that  part  inside  and  that  part 
outside . 

Since  protocols  come  nicely  layered,  an  obvious  proposal  is  that 
one  of  the  layer  interfaces  uhould  be  the  point  at  which  the  inside  and 
outside  conponents  are  sliced  apart.  Most  systems  have  been  implemented 
in  this  way,  and  many  have  been  made  to  work  quite  effectively.  One 
obvious  place  to  slice  is  at  the  upper  interface  of  TCP.  Since  TCP 
provides  a  bidirectional  byte  stream,  which  is  somewhat  similar  to  the 
I/O  facility  provided  by  most  operating  systems,  it  is  possible  to  make 
the  interface  to  TCP  almost  mimic  the  interface  to  other  existing 
devices.  Except  in  the  matter  of  opening  a  connection,  and  dealing  with 
peculiar  failures,  the  software  using  TCP  need  not  know  that  it  is  a 
network  connection,  rather  than  a  local  I/O  stream  that  is  providing  the 
communications  function.  This  approach  does  put  TCP  inside  the  kernel, 
which  raises  all  the  problems  addressed  above.  It  also  raises  the 
problem  that  the  interface  to  the  IP  layer  can,  if  the  programmer  is  not 
careful,  become  excessively  buried  inside  the  kernel.  It  must  be 
remembered  that  things  other  than  TCP  are  expected  to  run  on  top  of  IP. 
Ihe  IP  interface  must  be  made  accessible,  even  if  TCP  sits  on  top  of  it 
inside  the  kernel . 

Another  obvious  place  to  slice  is  above  Telnet.  The  advantage  of 
slicing  above  Telnet  is  that  it  solves  the  problem  of  having  remote 
login  channels  emulate  local  teletype  channels.  The  disadvantage  of 
putting  Telnet  into  the  kernel  is  that  the  amount  of  code  which  has  now 
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been  included  there  is  getting  remarkably  large.  In  some  early 


inqplementations,  the  size  of  the  network  package,  when  one  includes 


protocols  at  tlie  level  of  Telnet,  rivals  the  size  of  the  rest  of  the 


supervisor.  This  leads  to  vague  feelings  that  all  is  not  right. 


Any  attempt  to  slice  through  a  lower  layer  boundary,  for  exanple 


between  internet  and  TCP,  reveals  one  fundamental  problem.  The  TCP 


layer,  as  well  as  the  IP  layer,  performs  a  demultiplexing  function  on 


incoming  datagrams.  Until  the  TCP  header  has  been  examined,  it  is  not 


possible  to  know  for  which  user  the  packet  is  ultimately  destined. 


Therefore,  if  TCP,  as  a  whole,  is  moved  outside  the  kernel,  it  is 


necessary  to  create  one  separate  process  called  the  TCP  process,  which 


performs  the  TCP  multiplexing  function,  and  probably  all  of  the  refit  of 


TCP  processing  as  well.  This  means  that  incoming  data  destined  for  a 


user  process  involves  not  Just  a  scheduling  of  the  user  process,  but 


scheduling  the  TCP  process  first. 


This  suggests  an  alternative  structuring  strategy  wlilch  slices 


through  the  protocols,  not  along  an  established  layer  boundary,  but 


along  a  functional  boundary  having  to  do  with  demultiplexing.  In  this 


approach,  certain  parts  of  IP  and  certain  parts  of  TCP  are  placed  in  the 


kernel.  The  amount  of  code  placed  there  is  sufficient  so  that  when  an 


incoming  datagram  arrives,  it  is  possible  to  know  for  which  process  that 


datagram  is  ultimately  destined.  The  datagram  is  then  routed  directly 


to  the  final  process,  where  additional  IP  and  TCP  processing  is 


performed  on  ft.  This  removes  from  the  kernel  any  requirement  for  timer 


based  actions,  since  they  can  be  done  by  the  process  provided  by  the 
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user.  This  structure  has  the  additional  advantage  of  reducing  the 
amount  of  code  required  in  the  kernel,  so  that  it  is  suitable  for 
s^^stems  where  kernel  space  is  at  a  premium.  The  RFC  814,  titled  "Names, 
Addresses,  Ports,  and  Routes, "  discusses  this  rather  orthogonal  slicing 
strategy  in  more  detail. 

A  related  discussion  of  protocol  layering  and  multiplexing  can  be 
found  in  Cohen  and  Postel  [1] . 

5.  Breaking  Down  the  Barriers 

In  fact,  the  implementor  should  be  sensitive  to  the  possibility  of 
even  more  peculiar  slicing  strategies  in  dividing  up  the  various 
protocol  layers  between  the  kernel  and  the  one  or  more  user  processes. 
The  result  of  the  strategy  proposed  above  was  that  part  of  TCP  should 
execute  in  the  process  of  the  user.  In  other  words,  instead  of  having 
one  TCP  process  for  the  system,  there  is  one  TCP  process  per  connection. 
Given  this  architecture,  it  is  not  longer  necessary  to  imagine  that  all 
of  the  TCPs  are  identical.  One  TCP  could  bo  optimized  for  high 
throughput  applications,  such  as  file  transfer.  Another  TCP  could  be 
optimized  for  small  low  delay  applications  such  as  Telnet.  In  fact,  it 
would  be  possible  to  produce  a  TCP  which  was  somewhat  Integrated  with 
the  Telnet  or  FTP  on  top  of  it.  Such  an  integration  is  extremely 
important,  for  it  can  lead  to  a  kind  of  efficiency  vrtiich  more 
traditional  structures  are  incapable  of  producing.  Earlier,  thiis  paper 
pointed  out  that  one  of  the  important  rules  to  achieving  efficiency  was 
to  send  the  minimum  number  of  packets  for  a  given  amount  of  data.  The 
idea  of  protocol  layering  interacts  very  strongly  (and  poorly)  with  this 
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goal,  because  independent  layers  have  independent  ideas  about  when 
packets  should  be  sent,  and  unless  these  layers  can  somehow  be  brought 
into  cooperation,  additional  packets  will  flow.  The  best  example  of 
this  is  the  operation  of  server  telnet  in  a  character  at  a  time  remote 
echo  mode  on  top  of  TCP.  When  a  packet  containing  a  character  arrives 
at  a  server  host,  each  layer  has  a  different  response  to  that  packet. 
TCP  has  an  obligation  to  acknowledge  the  packet.  Either  server  telnet 
or  the  ajplication  layer  above  has  an  obligation  to  echo  the  character 
received  in  the  packet.  If  the  character  is  a  Telnet  control  sequence, 
then  Telnet  has  additional  actions  which  it  must  perform  in  response  to 
the  packet.  The  result  of  this,  in  most  implementations,  is  that 
several  packets  are  sent  back  in  response  to  the  one  arriving  packet. 
Combining  all  of  these  return  messages  into  one  packet  is  inportant  for 
several  reasons.  First,  of  course,  it  reduces  the  number  of  packets 
being  sent  over  the  net,  which  directly  reduces  the  charges  incurred  for 
many  common  carrier  tariff  structures.  Second,  it  reduces  the  number  of 
scheduling  actions  which  will  occur  inside  both  hosts,  which,  as  was 
discussed  above,  is  extremely  inportant  in  inproving  throughput. 

The  way  to  achieve  this  goal  of  packet  sharing  is  to  break  down  the 
barrier  between  the  layers  of  the  protocols,  in  a  very  restrained  and 
careful  manner,  so  that  a  limited  amount  of  information  can  leak  across 
the  barrier  to  enable  one  layer  to  optimize  its  behavior  with  respect  to 
the  desires  of  the  layers  above  and  below  it.  For  exanple,  it  would 
represent  an  inprovement  if  TCP,  when  it  received  a  packet,  could  ask 
the  layer  above  whether  or  not  it  would  be  worth  pausing  for  a  few 
milliseconds  before  sending  an  acknowledgement  in  order  to  see  if  the 


i 


upper  layer  would  have  any  outgoing  data  to  send.  Dallying  before 


sending  the  acknowledgement  produces  precisely  the  ri^t  sort  of 


optimization  if  the  client  of  TCP  is  server  Telnet.  However,  dallying 


before  sending  an  acknowledgement  is  absolutely  unacceptable  if  TCP  is 


being  used  for  file  transfer,  for  in  file  transfer  there  is  almost  never 


data  flowing  in  the  reverse  direction,  and  the  delay  in  sending  the 


acknowledgement  probably  translates  directly  into  a  delay  in  obtaining 


the  next  packets.  Thus,  TCP  must  know  a  little  about  the  layers  above 


it  to  adjust  its  performance  as  needed. 
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The  general  conclusioh  to  be  drawn  from  this  sort  of  consideration 
is  that  a  layer  boundary  has  both  a  benefit  and  a  penalty.  A  visible 
layer  boundary,  with  a  well  specified  interface,  provides  a  form  of 
isolation  between  two  layers  which  allows  one  to  be  changed  with  the 
confidence  that  the  other  one  will  not  stop  working  as  a  result. 
However,  a  firm  layer  boundary  almost  inevitably  leads  to  inefficient 
operation.  This  can  easily  be  seen  by  analogy  with  other  aspects  of 
operating  systems.  Consider,  for  exanple,  file  systems.  A  typical 
operating  system  provides  a  file  system,  which  is  a  highly  abstracted 
representation  of  a  disk.  The  interface  is  highly  formalized,  and 
presumed  to  be  highly  stable.  This  makes  it  very  easy  for  naive  users 
to  have  access  to  disks  without  having  to  write  a  great  deal  of 
software.  The  existence  of  a  file  system  is  clearly  beneficial.  On  the 
other  hand,  it  is  clear  that  the  restricted  interface  to  a  file  system 
almost  inevitably  leads  to  inefficiency.  If  the  interface  is  organized 
as  a  sequential  read  and  write  of  bytes,  then  there  will  bo  people  who 
wish  to  do  high  througtput  transfers  who  cannot  achieve  their  goal.  If 
the  interface  is  a  virtual  memory  interface,  then  other  users  will 
regret  the  necessity  of  building  a  byte  stream  interface  on  top  of  the 
memory  ma{^>ed  file.  The  most  objectionable  inefficiency  results  when  a 
highly  sophisticated  package,  such  as  a  data  base  management  package, 
must  be  built  on  top  of  an  existing  operating  system.  Almost 
inevitably,  the  implementors  of  the  database  system  attempt  to  reject 
the  file  system  and  obtain  direct  access  to  the  disks.  They  have 
sacrificed  modularity  for  efficiency. 

The  same  conflict  appears  in  networking,  in  a  rather  extreme  form. 
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Hie  concept  of  a  protocol  is  still  unknown  and  frightening  to  most  naive 
programmers.  The  idea  that  they  might  have  to  implement  a  protocol,  or 
even  part  of  a  protocol,  as  part  of  some  application  package,  is  a 
dreadful  thought.  And  thus  there  is  great  pressure  to  hide  the  function 
of  the  net  b^ind  a  very  hard  barrier.  C/n  the  other  hand,  the  kind  of 
inefficiency  which  results  from  this  is  a  particularly  undesirable  sort 
of  inefficiency,  for  it  shows  up,  among  other  things,  in  increasing  the 
cost  of  the  communications  resource  used  up  to  achieve  the  application 
goal.  In  cases  where  one  must  pay  for  one's  communications  costs,  they 
usually  turn  out  to  be  t^e  dominant  cost  within  the  system.  Thus,  doing 
an  excessively  good  Job  of  packaging  up  the  protocols  in  an  inflexible 
manner  has  a  direct  inpact  on  increasing  the  cost  of  the  critical 
resource  within  the  system.  This  is  a  dilemma  which  will  probably  only 
be  solved  when  programmers  become  somewhat  less  alarmed  about  protocols, 
so  that  they  are  willing  to  weave  a  certain  amount  of  protocol  structure 
into  their  application  program,  much  as  aj^lication  programs  today  weave 
parts  of  database  management  systems  into  the  structure  of  their 
application  program. 

An  extreme  example  of  putting  the  protocol  package  behind  a  firm 
layer  boundary  occurs  when  the  protocol  package  is  relegated  to  a  front- 
end  processor.  In  this  case  the  interface  to  the  protocol  is  some  other 
protocol.  It  is  difficult  to  imagine  how  to  build  close  cooperation 
between  layers  when  they  are  tliat  far  separated.  Realistically,  one  of 
the  prices  which  must  be  associated  with  an  implementation  so  physically 
modularized  is  that  the  performance  will  suffer  as  a  result.  Of  course, 
a  separate  processor  for  protocols  could  be  very  closely  integrated  into 
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the  mainframe  architecture,  with  interprocessor  co-ordination  signals, 
shared  memory,  and  similar  features.  Such  a  physical  modularity  mi^t 
work  very  well,  but  there  is  little  documented  experience  wich  this 
closely  coupled  architecture  for  protocol  support. 

6.  Efficiency  of  Protocol  Processing 

To  this  point,  this  document  has  considered  how  a  protocol  package 
should  be  broken  into  modules,  and  how  those  modules  should  be 
distributed  between  free  standing  machines,  the  operating  system  kernel, 
and  one  or  more  user  processes.  It  is  now  time  to  consider  the  other 
half  of  the  efficiency  question,  which  is  what  can  be  done  to  speed  the 
execution  of  those  programs  that  actually  irnplonent  the  protocols.  We 
will  make  some  specific  observations  about  TCP  and  IP,  and  then  conclude 
with  a  few  generalities. 

IP  Is  a  simple  protocol,  especially  with  respject  to  the  processing 
of  normal  packets,  so  it  should  be  easy  to  get  it  to  perform 
efficiently.  The  only  area  of  any  complexity  related  to  actual  packet 
processing  has  to  do  with  fragmentation  and  reassensbly.  The  reader  is 
referred  to  RFC  815,  titled  "IP  Datagram  Reassetnbly  Algorithms",  for 
specific  consideration  of  this  point. 

Most  costs  in  the  IP  layer  come  from  table  look  up  functions,  as 
opposed  to  packet  processing  functions.  An  outgoing  packet  requires  two 
translation  functions  to  be  performed.  The  internet  address  must  be 
translated  to  a  target  gateway,  and  a  gateway  address  must  be  translated 
to  a  local  network  number  (if  the  host  is  attached  to  more  than  one 
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network)  .  It  is  easy  to  build  a  sinple  irnplementation  of  these  table 
look  up  functions  that  in  fact  performs  very  poorly.  The  programmer 
should  keep  in  mind  that  there  may  be  as  many  as  a  thousand  network 
numbers  in  a  typical  configuration.  Linear  searching  of  a  thousand 
entry  table  on  every  packet  is  extremely  unsuitable.  In  fact,  it  may  be 
worth  asking  TCP  to  cache  a  hint  for  each  connection,  which  can  be 
handed  down  to  IP  each  time  a  packet  is  sent,  to  try  to  avoid  the 
overhead  of  a  table  look  up. 

TCP  is  a  more  complex  protocol,  and  presents  many  more 
opportunities  for  getting  things  wrong.  There  is  one  area  which  is 
generally  accepted  as  causing  noticeable  and  substantial  overhead  as 
part  of  TCP  processing.  This  is  computation  of  the  checksum.  It  would 
be  nice  if  this  cost  could  be  avoided  somehow,  but  the  idea  of  an  end- 
to-end  checksum  is  absolutely  central  to  the  functioning  of  TCP.  No 
host  Implementor  should  think  of  omitting  the  validation  of  a  checksum 
on  incoming  data. 

Various  clever  tricks  have  been  used  to  try  to  minimize  the  cost  of 
computing  the  ciiecksum.  If  it  is  possible  to  add  additional  microcoded 
instructions  to  the  machine,  a  checksum  instruction  is  the  most  obvious 
candidate.  Since  computing  the  checksum  Involves  picking  up  every  byte 
of  the  segment  and  examining  it,  it  is  possible  to  combine  the  operation 
of  computing  the  checksum  with  the  operation  of  copying  the  segment  from 
one  location  to  another.  Since  a  number  of  data  copies  are  probably 
already  required  as  part  of  the  processing  structure,  this  kind  of 
sharing  alg^*t  conceivably  pay  off  if  it  didn't  cause  too  much  trouble  to 
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the  modularity  of  the  program.  Finally,  confutation  of  the  checksum 
seems  to  be  one  place  where  careful  attention  to  the  details  of  the 
algorithm  used  can  make  a  drastic  difference  in  the  throughput  of  the 
program.  Ihe  Multics  system  provider  one  of  the  best  case  studies  of 
this,  since  Multics  is  about  as  poorly  organized  to  perform  this 
function  as  any  machine  implementing  TCP.  Multics  is  a  36 -bit  word 
machine,  with  four  9-bit  bytes  per  word.  The  eic^t-bit  bytes  of  a  TCP 
segment  are  laid  down  packed  in  memory,  ignoring  word  boundaries.  This 
means  that  when  it  is  necessary  to  pick  if  the  data  as  a  set  of  16 -bit 
units  for  the  purpose  of  adding  them  to  confute  checksums,  horrible 
masking  and  shifting  is  required  for  each  16 -bit  value.  An  early 
version  of  a  program  using  this  strategy  required  6  milliseconds  to 
checksum  a  576 -byte  segment.  Obviously,  at  this  point,  checksum 
computation  was  becoming  the  central  bottleneck  to  throug^tfut.  A  more 
careful  recoding  of  this  algorithm  reduced  the  checksum  processing  time 
to  less  than  one  millisecond.  The  strategy  used  was  extremely  dirty. 
It  involved  adding  if  carefully  selected  words  of  the  area  in  which  the 
data  lay,  knowing  tliat  for  those  particular  words,  the  16-blt  values 
were  properly  aligned  inside  the  words.  Only  after  the  addition  had 
been  done  were  the  various  sums  shifted,  and  finally  added  to  produce 
the  eventual  checksum.  This  kind  of  highly  specialized  programming  is 
probably  not  acceptable  if  used  everywhere  within  an  operating  system. 
It  i  i  clearly  appropriate  for  one  highly  localized  function  which  can  be 
clearly  identified  as  an  extreme  performance  bottleneck. 

Another  area  of  TCP  processing  which  may  cause  performance  problems 
is  the  overhead  of  examining  all  of  the  possible  flags  and  options  which 
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occur  in  each  incoming  packet.  One  paper,  by  Bunch  and  Day  [2],  asserts 
that  the  overhead  of  packet  header  processing  is  actually  an  inportant 
limiting  factor  in  throug^ut  conputation .  Not  all  measurement 
experiments  have  tended  to  support  this  result.  To  whatever  extent  it 
is  true,  however,  there  is  an  obvious  strategy  which  the  implementor 
ought  to  use  in  designing  his  program.  He  should  build  his  program  to 
optimize  the  expected  case.  It  is  easy,  especially  when  first  designing 
a  program,  to  pay  equal  attention  to  all  of  the  possible  outcomes  of 
every  test.  In  practice,  however,  few  of  these  will  ever  happen.  A  TCP 
should  be  built  on  the  assumption  that  the  next  packet  to  arrive  will 
have  absolutely  nothing  special  about  it,  and  will  be  the  next  one 
expected  in  the  sequence  space.  One  or  two  tests  are  sufficient  to 
determine  that  the  e^q^ected  set  of  control  flags  are  on.  (The  AOC  flag 
should  be  on;  the  Push  flag  may  or  may  not  be  on.  No  other  flags  should 
be  on.)  One  test  is  sufficient  to  determine  that  the  sequence  number  of 
the  incoming  packet  is  one  greater  than  the  ?ast  sequence  number 
received.  In  almost  every  case,  that  will  be  the  actual  result.  Again, 
using  the  Multics  system  as  an  exanple,  failure  to  optimize  the  case  of 
receiving  tne  e^qpected  sequence  number  had  a  detectable  effect  on  the 
performance  of  the  system.  The  particular  problem  arose  when  a  number 
of  packets  arrived  at  once.  TCP  attenpted  to  process  all  of  these 
packets  before  awaking  the  user.  As  a  result,  by  the  time  the  last 
packet  arrived,  there  was  a  threaded  list  of  packets  which  had  several 
items  on  it.  When  a  new  packet  arrived,  the  list  was  searched  to  find 
the  location  into  vhich  the  packet  should  be  inserted.  Obviously,  the 
list  should  be  searched  from  highest  sequence  number  to  lowest  sequence 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1G85 


22 

number,  because  one  is  expecting  to  receive  a  packet  which  comes  after 
those  already  received.  By  mistake,  the  list  was  searched  from  front  to 
back,  starting  with  the  packets  with  the  lowest  sequence  number.  The 
amount  of  time  spent  searching  this  list  backv/ards  was  easily  detectable 
in  the  metering  measurements. 

Other  data  structures  can  be  organized  to  optimize  the  action  which 
is  normally  taken  on  them.  For  example,  the  retransmission  queue  is 
very  seldom  actually  iLsed  for  retransmission,  so  it  should  not  be 
organized  to  optimize  that  action.  In  fact,  it  should  be  organized  to 
optimized  the  discarding  of  things  from  it  when  the  acknov^ledgement 
arrives.  In  many  cases,  the  easiest  way  to  do  this  is  not  to  save  the 
packet  at  all,  but  to  reconstruct  it  only  if  it  needs  to  be 
retransmitted,  starting  from  the  data  as  it  was  originally  buffered  by 
the  user. 

There  is  another  generality,  at  least  as  inportant  as  optimizing 
the  common  case,  which  is  to  avoid  copying  data  any  more  times  than 
necessary.  One  more  result  from  the  Multlcs  TCP  may  prove  enll^tenlng 
here.  Multlcs  takes  between  two  and  three  milliseconds  within  the  TCP 
layer  to  process  an  incoming  packet,  depending  on  its  size.  For  a  576- 
byte  pcicket,  the  three  milliseconds  is  used  up  approximately  as  follows. 
One  millisecond  is  used  conputing  the  checksum.  Six  hundred 
micro5ieconds  is  spent  copying  the  d^ta.  (The  data  is  copied  twice,  at 
.3  milliseconds  a  copy.)  One  of  those  copy  operations  could  correctly 
be  Included  as  part  of  the  checksum  cost,  since  it  is  done  to  get  the 
data  on  a  known  word  boundary  to  optimize  the  checksum  algorithm. 
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However,  tlie  copy  also  performs  another  necessary  transfer  at  the  same 
time.  Header  processing  and  packet  resequencing  takes  .7  milliseconds. 
The  rest  of  the  time  is  used  in  miscellaneous  processing,  such  as 
removing  packets  from  the  retransmission  queue  which  are  acknowledged  by 
this  packet.  Data  copying  is  the  second  most  expensive  single  operation 
after  data  checksuming .  Some  inplementations,  often  because  of  an 
excessively  layered  modularity,  end  up  copying  the  data  around  a  great 
deal .  Other  inplementations  end  up  copying  the  data  because  there  is  no 
shared  memory  between  processes,  and  the  data  must  be  moved  from  process 
to  process  via  a  kernel  operation.  Unless  the  amount  of  this  activity 
is  kept  strictly  under  control,  it  will  quickly  become  the  major 
performance  bottleneck. 

7 .  Conclusions 

This  document  has  addressed  two  aspects  of  obtaining  performance 
from  a  protocol  inplementation,  the  way  in  which  the  protocol  is  layered 
and  integrated  into  the  operating  system,  and  the  way  in  which  the 
detailed  handling  of  the  packet  is  optimized.  It  would  be  nice  if  one 
or  the  other  of  these  costs  would  completely  dominate,  so  that  all  of 
one's  attention  could  be  concentrated  there.  Regrettably,  this  is  not 
so.  Depending  on  the  particular  sort  of  traffic  one  is  getting,  for 
exanple,  whether  Telnet  one-byte  packets  or  file  transfer  maximum  size 
packets  at  maximum  speed,  one  can  expect  to  see  one  or  the  other  cost 
being  the  major  bottleneck  to  throughput.  Most  implementors  who  have 
studied  their  programs  in  an  attempt  to  find  out  where  the  time  was 
going  have  reached  the  unsatisfactory  conclusio-*  that  it  is  going 
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equally  to  all  parts  of  their  program.  With  the  possible  exception  of 
checksum  processing,  very  few  people  have  ever  found  that  their 
j  performance  problems  were  due  to  a  single,  horrible  bottleneck  which 

I  they  coi'^.d  fix  by  a  single  stroke  of  inventive  programming.  Ratl^er,  the 

‘  performance  was  something  which  was  inproved  by  painstaking  tuning  of 

I  the  entire  program. 

i 

\  Most  discussions  of  protocols  begin  by  Introducing  the  concept  of 

layering,  which  tends  to  suggest  that  layering  is  a  fundamentally 
wonderful  idea  which  should  be  a  part  of  every  consideration  of 
j  protocols.  In  fact,  layering  is  a  mixed  blessing.  Clearly,  a  layer 

Interface  is  necessary  whenever  more  than  one  client  of  a  particular 
layer  is  to  be  allowed  to  use  that  same  layer.  But  an  interface, 
precisely  because  it  is  fixed,  inevitably  leads  to  a  lack  of  complete 
j  understanding  as  to  what  one  layer  wishes  to  obtain  from  another.  This 

has  to  lead  to  inefficiency.  Furthermore,  layering  is  a  potential  snare 
in  that  one  is  tenpted  to  think  that  a  layer  boundary,  which  was  an 
artifact  of  the  specification  procedure,  is  in  fact  the  proper  boundary 
I  to  use  in  modularizing  the  Inplementatlon .  Again,  in  certain  cases,  an 

architected  layer  must  correspond  to  an  implemented  layer,  precisely  so 
that  several  clients  can  have  acces.s  to  that  layer  in  a  reasonably 
straightforward  manner.  In  other  cases,  cunning  rearrangement  of  the 
Inplemented  module  boundaries  to  match  with  varlo^js  functions,  such  as 
the  demultiplexing  of  incoming  packets,  or  the  sending  of  asynchronous 
outgoing  packets,  can  lead  to  unexpected  performance  .improvements 
I  compared  to  more  traditional  Inplementatlon  strategies.  Finally,  good 

performance  is  something  which  is  difficult  to  retrofit  onto  an  existing 
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program.  Since  performance  is  influenced,  not  just  by  the  fine  detail, 
but  by  the  gross  structure,  it  is  sometimes  the  case  that  in  order  to 
obtain  a  substantial  performance  inprovement,  it  is  necessary  to 
completely  redo  the  program  from  the  bottom  up.  This  is  a  great 
disappointment  to  programmers,  especially  those  doing  a  protocol 
implementation  for  the  first  time.  Programmers  who  are  somewhat 
inexperienced  and  unfamiliar  with  protocols  are  sufficiently  concerned 
with  getting  their  program  logically  correct  that  they  do  not  have  the 
capacity  to  think  at  the  same  time  about  the  performance  of  the 
structure  they  are  building.  Only  after  they  have  achieved  a  logically 
correct  program  do  they  discover  that  they  have  done  so  in  a  way  which 
has  precluded  real  performance.  Clearly,  it  is  more  difficult  to  design 
a  program  thinking  from  the  start  about  both  logical  correctness  and 
performance.  With  time,  as  implementors  as  a  groip  learn  more  about  the 
appropriate  structures  to  use  for  building  protQ‘.‘:ols,  it  will  be 
possible  to  proceed  with  an  implementation  project  having  more 
confidence  that  the  structure  is  rational,  that  the  program  will  work, 
and  that  the  program  will  work  well.  Those  of  us  now  implementing 
protocols  have  the  privilege  of  being  on  the  forefront  of  this  learning 
process.  It  should  be  no  surprise  that  our  programs  sometimes  suffer 
from  the  uncertainty  we  bring  to  bear  on  them. 
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Absiraci—A  protocol  that  supports  the  sharinf  of  resources  that 
exist  in  different  packet  switching  networks  is  presented.  The  proto¬ 
col  provides  for  variation  in  individual  network  packet  sixes,  trans¬ 
mission  failures,  sequencing,  flow  control,  end-to-end  error  checking, 
and  the  creation  and  destruction  of  logical  process-to-process  con¬ 
nections.  Some  implementation  issues  are  considered,  and  problems 
such  as  internetwork  routing,  accounting,  and  timeouts  are  exposed. 

IXTRODUCTIOX 

X  THE  LAST  f(‘w  years  ronsidorabk*  effort  has  Wn 
expendcKl  on  the  design  and  im|)l<*m(‘ntation  of  packet 
switching  networks  Cl]-[7].Cl4].[17].  A  principh'  n‘ason 
for  developing  such  n<*t\vorks  has  been  to  facilitate  the 
sharing  of  computer  n'S(iurces.  A  packet  communication 
network  includes  a  transp<»rtation  mechanism  for  deliver¬ 
ing  data  between  computers  or  b(‘tw<*en  computers  and 
terminals.  To  make  thi*  data  m<*aningful,  computi*rs  and 
terminals  share  a  common  pmtiK-ol  (i.e.,  a  set  of  agn*ed 
upon  conventions).  Si'veral  protocols  havi*  already  been 
developed  for  this  purpos<>  Howev<*r. 

these  pnitoccls  have  addn'ssi'd  only  the  problem  of  com¬ 
munication  on  the  same  network.  In  this  pap<*r  we  pnsient 
a  protocol  design  and  philosophy  that  supp<»rts  the  sharing 
of  resources  that  exist  in  differ<*nt  packet  switching  net¬ 
works. 

After  a  bri<*f  intr<Klucti<in  to  internetwork  jirotocol 
is.sues,  we  describe  the  function  of  a  <jateway  as  an  inter¬ 
face  betw(>cn  network.N  and  discuss  its  roh*  in  the  protocol. 
We  then  consider  the  various  details  of  the  pn)ti>col, 
including  addressing,  formatting,  buffering,  siHjuencing. 
flow  control,  ernir  control,  and  so  forth.  We  closi*  with  a 
di'scriptioo  of  an  interpr<ices.s  communication  nmehanism 
and  .show  how  it  can  bt*  suppfirted  by  th<*  internetwork 
protocol. 

Even  though  many  different  and  complex  pniblems 
mu.st  be  solved  in  the  d(*sign  of  an  individual  packi't 
switching  network,  these  problems  are  manif«*stly  com- 
poundfsl  when  dissimilar  networks  are  interconnected. 
Imu<*s  arise  which  may  have  no  direct  counterpart  in  an 
individual  network  and  which  slnmgly  influence  the  way 
in  which  internetwork  communication  can  take  place. 

A  typical  packet  switching  network  is  composed  of  a 
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set  of  computer  rt'sources  calltd  hosin.  a  set  t*f  one  or 
more  ptichct  snitches,  and  a  ctillectitm  of  communication 
mtdia  that  intt*rronnect  the  packet  switcht's.  Within 
each  HOST,  wc  assume  that  there  exist  pritrvs.sc.<<  which 
must  communicate  with  processes  in  their  t>wn  «»r  other 
Ho.srs.  .\ny  current  definition  of  a  process  will  be  adetjuate 
for  our  purjwises  These  processes  are  generally  the 

ultimate  .“ouns*  and  destinati»>n  of  data  in  th<*  mdwork. 
Typically,  within  an  ii.dividual  network,  then*  (‘xists  a 
prot«)Col  for  communication  between  any  sourci*  and 
d(‘stination  proc<*ss.  Only  tin*  source  and  (li*stination 
pr<')C<*sses  n*<|uire  knowle<lg<*  of  this  conv<*ntion  for  coni- 
niunication  to  tak<*  placi*.  Processes  in  two  distinct  net¬ 
works  would  ordinarily  u<e  different  pmtoeols  for  this 
purisisi*.  Tin*  ensemble  of  pack<*t  switcln*s  and  com¬ 
munication  nndia  is  cnllid  tin*  paclct  Htrftch\ug  subnet. 
Fig.  1  illustrati's  rln*s(*  ideas. 

In  a  typical  park<*t  switching  subm*t,  data  of  a  fixed 
maximum  sizi*  an*  ae<*ept<sl  fn»m  a  source  host.  tog(*ther 
with  a  formatted  d<*stination  addn'ss  which  is  used  to 
mute  the*  data  in  a  ste*re*  and  feirward  fashie*n.  The*  transmit 
time  feir  this  data  is  usually  de*|)e*nde*nt  u|>on  inte*rnal 
m'tweirk  paraineteTs  such  as  cemnnunicatlein  media  data 
rate's,  buffering  and  •signaling  strate*gie*s.  niuting.  pn»pa- 
gatiein  de'lnys.  e  tc.  In  additiem.  some*  nnshnni^m  is  gen¬ 
erally  pn*se*nt  fe»r  ermr  h.indliteg  and  de*te*rminatie)n  eif 
status  eif  the*  ne*twe>rk.s  cemijsme'nts. 

Individual  packe*t  switching  tn*tweirks  may  diff(*r  in 
the*lr  imple*me*ntatie*iis  as  feilleiws. 

1 )  I'^eh  ne*twe)rk  may  have  di*<tine*t  ways  e*f  addre'ssing 
the*  n*reive*r.  thus  ns|uiring  that  a  uniform  adeln*ssing 
sche*me  lx*  cn*ated  which  e*an  lx*  unele*r>t«Md  fiv  e*ach 
individual  in  tweirk. 

2)  Eae  h  in*twork  may  acee*pt  elata  «*f  dilTe*n*nt  maximum 
size,  thus  res|uiring  ne*tw«*rks  to  de*al  in  units  of  the 
smalle*st  maximum  size*  (which  may  In*  impractically 
small)  or  nsjuiring  pns'edun***  which  allow  data  crtissjng 
a  nf'tweirk  lx»undiiry  to  lx*  n*formatt<d  into  smaller 
pie*res. 

:i)  The  «tucce*ss  or  failun*  e»f  u  transmissieni  and  its  per- 
feirmance*  in  earh  ne'twork  is  gove*nnd  by  difT**n*nt  time* 
de*bys  in  .*n*e'*  |>ting.  ele*liv**ring,  and  trans|x)rting  the*  data. 
Thi^  rr<|uin*s  ran*fiil  de*v«*|o|Mnc*nt  *»f  inte*nn*twork  timing 
pniridun***  t*»  insun*  that  data  ran  *m*  ■«urre'*sfully  de*- 
liv**nd  thmugh  tin*  variem-  ne*twe*rks. 

4)  W'itliin  e*arh  network.  r*imniu»ie*ation  may  lx*  dis- 
rupTed  du**  to  einnsM»v**ral>l**  mutution  of  the  data  or 
mi’*sing  data.  Knel-t<.^*nel  n—i oration  pn.'ceslures  an* 
d«**'irable*  t**  allow  r*nnpl**t**  n*c*»ve*rv  fn»m  thoe*  ron- 
diUon-H. 


-  19T4  1!  I  I  ,  Kt'iomtcil  wsfh  permnsion,  from  //77-.‘  <*«  Oftnitiutticjiittns.  \'ol.  (\-en-22.  .No  5. 
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FACKcT  SWItCHINti  NETMOMK  ft  •  fACKET  CWITCN 

Fig.  1.  Tj-piosl  packet  svitohing  network. 

o''  Status  information,  routiii^,  fault  detection,  and 
isolation  are  typieally  different  in  each  network.  Thus,  to 
obtain  verification  of  certain  conditions,  such  as  an  in¬ 
accessible  or  dead  destination,  various  kinds  of  coordi¬ 
nation  must  be  invoked  betwes'ii  the  communicating  net¬ 
works. 

It  would  be  extrenmly  ceinvenient  if  all  the  differences 
betwwn  networks  could  be*  efonomically  resolved  by 
suitable  interfacing  at  the  net\York  boundaries.  For 
many  of  the  differences,  this  objective  can  be  achieved. 
However,  both  economic  and  t<‘chnical  considerations  lead 
us  t<t  prefer  that  the  interface  be  as  simple  and  reliable 
as  p<is.sible  and  deal  primarily  with  passing  data  between 
networks  that  use  different  packet  switching  strategies. 

The  question  now  arises  as  to  whether  the  interface 
ought  to  account  for  differences  in  host  or  process  level 
protocols  by  transforming  the  source  conventions  into  the 
corres|K)ndiiig  destination  conventions.  We  obviously 
want  to  allow  conversion  b<-tween  packet  switching 
strati'gii's  at  the  interface,  to  permit  interconnection  of 
existing  and  planiK'd  in-tworks.  However,  the  complexity 
and  dissimilarity  of  th<*  host  or  pn»cess  level  protocols 
makes  it  desirable  to  avoid  having  to  transform  between 
them  at  the  interface,  even  if  this  transfonnation  were 
always  iMissible.  Hather,  enmjiatihle  host  and  proei*ss 
lev«'l  prntiKols  must  Ix’  deve|o|M>d  to  achieve  eff<*ctive 
internetwork  n-source  sharing.  The  unaceeptahle  al¬ 
ternative  is  f«  Try  ho.st  or  pr«K-«*ss  to  implement  every 
prot««-t»l  la  ix»t‘  .tially  unlxiundixl  numlMT)  that  may  b<* 
iHs^hnl  tn  conununicute  with  other  networks.  \\\  then*- 
htre  us-uiiie  that  a  eoninioii  protix'ol  is  to  hi-  used  ImIwisii 
host’s  nr  pnKM-ss^-s  in  different  networks  and  that  the 
interfaee  Ix-tw^  n  networks  should  take  as  small  a  mle  us 
ixtssible  in  this  pnttix'ol. 

To  allow  networks  under  different  ownership  to  inter- 
eonneet.  sonie  ueeoiinting  will  undoubtedly  lx-  iw<>d«*d  for 
t raffle  that  pass<*s  aeniss  the  interface.  In  its  simplest 
terui^.  thi‘-  involves  an  ueeoiintiug  of  packets  hniidhsl  by 
each  net  for  which  rharg«*^  an*  passi-d  fn»ni  net  to  net 
until  the  buck  finally  stops  at  the  us<*r  or  his  n*pn*senta- 
tive.  I  urt henoore.  the  inten*onn«*ction  must  pn*s«*rve 


intact  the  internal  oi>eration  of  (*ach  individual  network. 
This  is  easily  achieved  if  two  networks  interconnect  as 
if  each  were  a  host  to  the  other  network,  but  without 
utilizing  or  indei*d  incor|xirating  any  elal^irate  host 
protocol  transformations. 

It  is  thus  apjiarent  that  the  interfaee  lietween  networks 
must  play  a  central  role  in  the  devi'lopment  of  any  net¬ 
work  interconnection  strati*gy.  We  give  a  sjvcial  name  to 
thi.s  interface  that  perfonns  thesi*  functions  and  call  it  a 
gateway. 

THE  GATEWAY  XOTIOX 

In  Fig.  2  we  illustrate  thns*  individual  networks  lab<*h‘d 
A,  li,  and  ('  which  are  joined  by  gatew.os  M  and  .Y. 
CATEAVAY  M  interfaces  network  .!  with  network  Ji,  and 
gateway  .V  interfacis  network  fi  to  network  C.  Wa 
assume  that  an  individual  network  may  have  more  than 
one  gateway  (e.g.,  network  B)  and  that  there  may  be 
more  than  om*  gateway  path  to  use  in  going  between  a 
pair  of  networks.  Thi*  resiwinsibility  for  properly  routing 
data  resides  in  the  gateway. 

In  practiw*.  a  gateway  between  two  networks  may  be 
composed  of  two  halves,  each  as.soeiati'd  with  its  own 
network.  It  is  pos.siblc  to  implement  each  half  of  a  gate¬ 
way  so  it  ne<*d  only  embed  internetwork  packets  in  local 
packet  format  or  extract  them.  We  propose  that  the 
gateways  handle  internetwork  packets  in  a  standard 
format,  but  we  are  not  proposing  any  particular  trans¬ 
mission  proci'dure  between  gate^'ay  halves. 

Let  us  now  trace  the  flow  of  data  through  the  inter¬ 
connected  networks.  Wi*  assume  a  packet  of  data  from 
procf's.s  A'  enters  network  A  destinKi  for  process  )*  in 
network  C.  Tin*  address  of  1'  is  initially  sisrifii-d  by 
process  A’  and  the  addn'ss  of  gateway  M  is  derivi'd  from 
the  addn'ss  of  process  We  make  no  attempt  to  siKTify 
whether  the  choice  of  (iateway  is  made  by  proei'ss  X, 
its  HOST,  or  one  of  the  packet  switeli«*s  in  network  .4.  The 
packet  traversi's  network  A  until  it  reaches  (s.^tevvay  M. 
At  the  GATE^VAY,  the  paeket  is  n‘formntti*d  to  nus*t  the 
nspiiirments  of  network  li,  account  is  taken  of  thi'  unit 
of  flow  lx*twn*n  .1  and  B,  aiui  the  gatew.u  tleliver'^  the 
iweket  to  network  B.  .\gain  the  derivation  of  the  lyxt 
gateway  addn*ss  is  aeeomplishe<l  has4>tl  on  the  :Hhln‘*‘s  of 
the  diNtination  Y.  In  this  cas«*.  gateway  .V  is  the  next  one. 
The  paeket  trnversis  network  B  until  it  finally  reaches 
GATE^VAY  .V  when*  it  is  fonuattMl  to  nns-t  the  ris|uin  inents 
of  network  ('.  .Veeount  is  again  taken  of  thh  unit  of  flow 
b«*twn*n  networks  B  ami  rjMui  entering  network  (\ 
the  packet  is  n»uti*d  to  the  most  in  which  pnK*«s.s  )' 
n*sides  and  then*  it  is  (|eliven*<i  to  it>  nltimate  di*stiii:ition. 

SiiuM*  the  e.ATKWAY  must  understand  the  addn*****  of  tie. 
s«»uree  and  di'stination  hosts,  this  information  nnist  lx* 
avaihihh*  in  n  stand:inl  fonnat  in  every  packet  which 
arrives  at  the  gateway.  This  information  h  eont:iin«*d 
ill  an  m/erm hnuhr  pn*fi\ed  to  the  paeket  hy  the 
source  HOST,  llie  |»acket  fonnat.  inehiding  the  internet- 
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Fig.  2.  Three  networks  interntnnected  by  two  oateways. 


[lOCAL  MtOOtAiMMWCt  iotttWUTKPlillOUiNCi  SO  HvTI  COUWTIkaB  »lfCO|  Ti«T~^C«SUM| 

Fig.  3.  Internetwork  packet  format  (fields  not  shown  to  s<*ale). 


work  header,  is  illastratod  in  Mr.  3.  The  source  and  desti¬ 
nation  entri(*s  uniformly  and  uiii<|in*ly  identify  the  address 
of  ever>'  host  in  the  composit<*  network.  Addrea.sinR  is  a 
subject  of  considerable  complexity  which  is  discu.<sed 
in  girater  detail  in  the  next  section.  The  next  two  entries  in 
the  header  provide  a  se<|uence  number  and  a  byte  count 
that  may  be  used  to  pro|)erly  se(|uence  the  packets  upon 
delivery  to  the  destination  and  may  also  ('liable  the 
oateti'ays  to  detect  fault  oonditions  afTecting  the  packet. 
The  flag  field  is  ust'd  to  convey  specific  eontml  information 
and  is  discu.s-sed  in  the  section  on  retransmission  and 
duplicate  detection  later.  The  remainder  of  the  packet 
con.sists  of  text  for  deliver>'  to  the  destination  and  a  trailing 
check  sum  u.sed  for  end-to-end  software  vi'rification.  The 
OATET^'AY  does  TUit  mcxlify  the  text  and  merely  fonvards  the 
cheek  sum  along  without  computing  or  recomputing  it. 

Each  network  may  nc^'d  to  augiiK'iit  the  packet  format 
before  it  can  pass  through  the  individual  network.  We 
have  indicat  I'd  a  htcol  holder  in  the  figure  which  is  prefixed 
to  the  beginning  of  the  packet.  This  local  header  is  intro- 
ducesi  merely  to  illustratt'  the  concept  of  embedding  an 
internetwork  packet  in  the  format  of  the  individual  net¬ 
work  through  which  the  packet  must  pas.s.  It  will  ol>- 
viously  vary  in  its  (‘xact  f(»rm  fn»m  network  to  •M*tw('rk 
and  may  even  be  unnecessnr>'  in  som.'  .-'asex.  .Mt  hough  not 
explicitly  indicat(*d  in  the  figure,  it  is  also  |»ossible  that  a 
h>cal  trailer  may  lie  appended  t»»  the  end  td  the  packet. 

Unless  all  transmitted  packets  are  legislatively  n'- 
stricted  to  be  small  enough  to  lie  acro|)ted  by  every  in¬ 
dividual  network,  the  c.ateway  may  b('  forc<sl  to  split  a 
packet  into  two  or  more  smaller  jiackets.  This  action  is 
called  fragment  at  i«tn  and  must  Is*  dom*  in  such  a  way  that 
the  diMinathm  is  able  to  piece  together  the  fragni('iit('d 
packet.  It  is  ch'ar  that  the  internetwork  header  format 
imposes  a  minimum  packet  site  which  all  networks 
must  carry  (obviou.sly  all  networks  will  want  to  caiT.% 
packets  larger  than  this  minimum).  We  lielieve  the  long 
range  growth  and  development  of  internetwork  ctim- 
munication  would  be  s4-riously  inhibit«sl  by  >|Ms-ifying 
how  much  larger  than  the  minimum  a  pnck«-t  size  can  1m\ 
for  the  billowing  re:Ls«»ns. 

I )  If  a  maximum  ;>ermitied  |Kicket  -ize  is  >|ss*ili<*d  then 
it  becomes  im])o>sible  to  completely  is<ilate  the  intemai 
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packet  size  parameters  of  one  network  from  the  internal 
packet  size  parameters  of  all  other  networks. 

2)  It  would  be  very  difficult  to  increasi*  the  maximum 
permittc'd  pack(’t  size  in  resjionse  to  new  teehnol<»g>'  (e.g., 
large  memorx*  sy.stems.  highiT  data  rati'  communication 
facilitii's.  etc.)  sinci'  this  would  reipiin*  the  agnsmient  and 
th('n  implementation  by  all  participating  networks. 

3)  Associative  addressing  and  packet  encryption  may 
requirt'  the  .size  of  a  particular  packet  to  expand  during 
transit  for  ineor|H»ration  of  new  information. 

Provision  for  fragmc'ntation  (regardless  of  where  it  is 
performed)  permits  packi't  size  variations  to  be  handh'd 
on  an  individual  network  basis  without  gl(*bal  admin¬ 
istration  and  also  ix'rmits  hosts  and  proc("'S(>s  to  be 
insulati'd  from  changi's  in  the  packet  size«i  |R‘rmitted  in 
any  ni'tworks  through  which  their  data  must  pass. 

If  fragmentation  must  be  done,  it  ap|)ears  Is'st  to  do  it 
upon  enti'ring  the  next  network  at  the  catew.ay  since  only 
this  r.ATEWAY  (and  not  the  other  networks)  must  Ik*  aware 
of  the  int<*rnal  packet  size  parami'ters  which  made  the 
fragmentation  nec(*ssary. 

If  a  r.ATEWAY  fragmi'nts  an  incoming  packet  into  two  or 
more  packi'ts,  they  must  eventually  1h*  pass(>d  ahmg  to  the 
destination  host  as  fragments  or  n*:iss(*mbl(‘d  for  the 
HOST.  It  is  concc'ivabh*  that  one  might  desiri'  the  o.yteway* 
to  perform  the  rt*as.'*(*mbly  to  simplify  tin*  task  <»f  the  desti¬ 
nation  HOST  ((»r  proei'ss)  and  or  to  take  advantage  of  a 
larger  packet  size.  We  taki*  the  |K)siti(»n  that  gateway's 
should  not  pc'rform  this  function  sinci*  oatewav  re¬ 
assembly  can  lead  to  si'rious  bufTering  prolilems,  potential 
deadliK*ks.  the  ni'ci'ssity  for  all  fragments  of  a  packet  to 
pass  through  tlie  same  c.ateiy’.xy*,  and  increasi'd  delay  in 
transmission,  l•‘urthermo^e,  it  is  not  sufficient  for  the 
UAFEWAYs  to  provide  this  function  since  the  final  c.ateway 
may  also  have  to  fr.igment  a  packet  for  transmission. 
Thus  the  destination  host  must  be  prepar'd  to  do  this 
task. 

Ijct  us  now  turn  briefly  to  the  somewhat  unusual  ac¬ 
counting  efTi'ci  whirh  arises  when  a  packet  may  bi*  frag- 
menti'd  by  oi^e  or  mop'  gateways.  We  assume,  for 
sim|)licity.  that  each  network  initially  charges  a  fixed  rate 
fK'r  packet  transmitted,  .-eganlless  of  distance,  and  if  one 
network  cun  haiidh*  a  larger  packet  ^ize  tlian  another,  it 
chzirgi's  a  pro|K*rfionally  larger  price  |K*r  packet.  We  also 
as-snine  that  a  snbsinuent  increa's*  in  any  network’a 
packet  size  din's  not  ri'snlt  in  additional  cost  |>er  packet  to 
its  users.  The  charge  to  a  user  thus  remains  basically 
constant  through  any  net  wbieli  must  fragment  a  packet. 
The  unusual  elTis't  iK-eurs  when  a  packet  is  fragmenti'd  into 
smaller  packets  which  must  individually  pass  through  a 
Hubs4i)ueni  network  with  a  larger  packet  size  than  the 
original  unfragineiitcd  packet.  We  cxiK*et  that  most  net¬ 
works  will  naturally  sch'ct  p:ickct  sizes  close  to  one 
another,  but  in  ai»y  CiW*.  an  incrcao-  in  packet  size  in  one 
net.  even  when  it  causes  fragmentation,  will  not  increase 
the  cost  of  tranMiiissiini  and  may  actually  decrease  it.  In 
the  event  that  any  other  packet  cluarging  jxilicies  (than 
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the  one  we  suggi'st)  are  adopted,  differences  in  cost  can  be 
used  as  an  economic  lever  toward  optimization  of  indi¬ 
vidual  network  performance. 

PROCESS  LEVEL  COMMUNICATION 

We  suppose  that  processes  wish  to  communicate  in  full 
duplex  with  their  correspondents  using  unbounded  but 
finite  length  messages.  A  single  character  might  constitute 
the  text  of  n  message..irom  a  prorca;  to  a  terminal  or  vice 
versa.  An  entire  page  of  characters  might  constitute  the 
text  of  a  nn^ssage  from  a  file  to  a  process.  A  data  stream 
(e.g.,  a  continuously  generati'd  bit  string)  can  be  repre¬ 
sented  as  a  sequence  of  finite  length  messages. 

Within  a  host  we  assume  the  existence  of  a  transmission 
control  program  (TCP)  which  handles  the  transmis-sion 
and  acceptance  of  messages  on  behalf  of  the  processes  it 
serves.  The  TCP  is  in  turn  served  by  one  or  more  packet 
switches  connected  to  the  host  in  which  the  TCP  resides. 
Proces-ses  that  want  to  communicate  present  messages 
to  the  TCP  for  transmission,  and  TCP’s  deliver  incoming 
messages  to  the  appropriate  destination  processes.  We 
allow  the  TCP  to  break  up  mes.sages  into  segments  be¬ 
cause  the  destination  may  restrict  the  amount  of  data  that 
may  arrive,  because  the  local  network  may  limit  the 
maximum  transmission  size,  or  because  the  TCP  may 
need  to  share  its  resources  among  many  processes  con¬ 
currently.  Furthermore,  we  constrain  the  length  of  a 
segment  to  an  integral  number  of  S-bit  bytes.  This  uni¬ 
formity  i**  most  helpful  in  simplifying  the  software  needed 
with  HOST  macliines  of  diffen-iit  natural  word  lengths. 
Provision  at  the  process  level  can  lx*  madi*  for  padding  a 
message  that  is  not  an  int(‘gral  number  of  bytes  and  for 
identifying  which  of  the  arriving  bytes  of  text  contain 
information  of  interest  to  the  receiving  pnicess. 

Multipli'xing  and  demultiph'xing  of  segments  among 
processes  are  fundamental  tasks  of  the  TCP.  On  trans¬ 
mission.  a  TCP  must  nuiltipl«‘x  together  s«*gments  from 
diffeniit  source  pnK*«*ss«s  and  pneduce  intem«‘twork 
packets  fi»r  d«  iiv«‘ry  to  one*  of  its  serving  packet  switches. 
On  nse-pilfiii.  a  TCP  will  accept  a  sesiuence  of  pack(*ts 
from  it-  -erviisg  packet  switch(«*s'l.  Kniin  this  se<|uencc 
of  arriving  packets  (generally  from  diffenait  m*sTs). 
the-  TCP  must  he  able*  t«»  n-construct  and  deliver  messages 
te>  the*  projM  r  ele*stinatie>n  pn>cess«*s. 

We*  assume'  that  e*very  se*gme*nt  is  augim  r.lr'd  with  ad- 
ditiemal  information  that  allows  transmitting  and  n*- 
ce*iving  T('!*’s  te>  ieli*ntify  destinatieni  and  se>um*  pnicesses, 
rtspe*ctive*l\ .  At  this  |»oint.  w«*  must  face*  a  inajeir  issue. 
How  shoulel  the*  se>ure*e*  TCP  feerimit  segme*nts  de*stine*d  feir 
the*  same*  de  stinatiiin  TCP?  We*  e*onside*r  twei  cases. 

('nt.c  1)  If  we*  iuke*  the*  |Hisiti<in  that  se*gme*nt  benmdaries 
are*  iminate*rial  and  that  a  hyte*  .stre*nm  can  Is*  feirme*d  of 
se*gme*nt-  distiin*t!  for  the*  same*  TCP,  the*n  we*  ma>  gain 
impreevid  transmission  e  ffie*ie*ne*y  and  re'source*  sharing  by 
arbitrarily  pare*e*ling  the*  stre*:im  inte>  packets,  |)e‘rmitting 
many  se*gme‘nts  te>  share*  a  single*  inte*metwork  packe*t 
he*ade*r.  Ho\ve*ve*r.  this  positiein  re‘sult>i  in  the  ne*<*d  te>  re^ 


ce)nstruct  exactly,  and  in  e)rde*r,  the*  stream  of  text  bytes 
produced  by  the  seiurce  TCP.  At  the  dc‘Stination,  this 
stream  must  first  be*  parse*d  inte>  segments  and  these  in 
turn  must  be*  use*d  to  re*oe)nstruct  message*s  for  de*liver>'  to 
the  appropriate*  preK*e*s.s(*s. 

There  are*  fundamental  problems  asseiciated  with  this 
strate*gy  due*  to  the*  po.ssible*  arrival  of  packe*ts  out  of  order 
at  the  de*stinatie>n.  The*  me»st  critical  problem  appe*ar8 
tee  be  the  amount  e>f  int(*rfe*rence*  that  preecesses  .sharing  the 
narrie  TCP-TCP  byte*  sin*am^ may  cause*  among  them- 
selve*s.  This  is  esp(*cially  se>  at  the*  re*ceiving  end.  I'irst, 
the  TCP  may  be*  put  to  semte  tremble  to  parse  the*  stream 
back  into  se*gments  and  then  distribute*  them  to  buffers 
where  mcssage*s  are*  reas.sembled.  If  it  is  not  readil.v  ap¬ 
parent  that  all  of  a  segment  has  arrived  (remember,  it 
may  come  as  8eve*ral  packets),  the  r(‘ceiving  TCP  may 
have  to  suspend  parsing  tempeirarily  until  more  packets 
have  arrived.  Second,  if  a  packet  is  missing,  it  may  not  be 
clear  whether  succeeding  segments,  even  if  they  are  identi¬ 
fiable,  can  be  passed  on  to  the  receiving  process,  unless  the 
TCP  has  knowledge  of  some  process  level  sequencing 
scheme.  Such  knowledge  would  permit  the  TCP  to  decide 
whether  a  succeeding  segment  could  be  delivered  to  its 
waiting  process.  Finding  the  beginning  of  a  segment  when 
there  arc  gaps  in  the  byte  stream  may  also  be  hard. 

Casf  2) :  Alternatively,  we  might  take  the  position  that 
the  destination  TCP  should  be  able  to  determine,  upon 
its  arrival  and  without  additional  information,  for  which 
process  or  processes  a  received  packet  is  intended,  and  if 
so.  whether  it  sh»»uld  be  deliver(*d  then. 

If  the  TCP  is  to  d(*termin(*  for  which  proc(*ss  an  arriving 
packet  is  int(*nded,  (*very  packet  must  contain  a  prurcss 
hraticr  (distinct  from  th(*  internetwork  header)  that  com- 
plet(*ly  identifi(*s  tin*  destination  proc(*ss.  For  simplicity, 
w(*  assume  that  (*ach  pack(*t  contains  t(*xt  from  a  single 
proc(‘s.s  which  is  d(*stin('d  for  a  single  proc(*ss.  Thus  (*ach 
packet  n(*<*d  contain  only  one  pnK*«*ss  head«*r.  To  d«*cidc 
wlH*th(*r  tin*  arriving  data  i-  (b*liv(*rabl(*  to  the  destination 
process,  the  TCP  must  lx*  able  to  di  tenviim*  wheth(*r  the 
data  is  in  the  prop<*r  st*<|U(*nc(*  (w(*  can  make  provision 
for  the  d(*stiuatioi\  pn>c«*s-i  to  instruct  its  TCP  to  ignore 
s<*qn«*ncing.  but  this  i-  consitb*n*<l  a  sp<*t*ial  cas(*).  With  the 
assioiiptioii  that  (*nch  arriving  pack(*t  contains  a  proc(*ss 
h«*ader.  tin*  iu*c«*ssary  setiueneing  and  d«*stination  proc(*s.s 
id'*ntification  is  immediat(*ly  availabb*  to  tin*  d(*stij*atiun 

TCP. 

Both  Cas«*-  1)  and  2)  provid«*  for  tin*  dcmultipl(*xing 
and  delivery  of  wgments  to  d(*stination  pn)Cf‘ss(*s,  but 
only  Cas(*  2)  diK*s  S4>  without  the  intriKluction  of  |K>tential 
interproc(*sH  int«*rf(*n*nc(*.  Furtln*mn>r(*.  Ca.se  1)  intn»duces 
(*xtra  machir.ery  to  handb*  flow  control  on  a  HosT-to- 
HosT  basis,  sinc«*  then*  must  also  lx*  sonn*  provision  for 
pnK*«*ss  b*v«'l  control,  and  tins  m:ichin(*ry  is  little  us«*d  since 
the  pnibability  i>  small  that  within  a  given  ho.st.  two 
pn*c«*ss(*s  will  Ik-  (*oincid(*ntall>  scb«*tlul«*d  to  s«*nd  nn*ssages 
t«»  tin*  saiin*  di*stination  ho.st.  I'or  this  reason.  w(*  s(*b‘(*t 
the  method  of  Cas«*  2)  a-  a  part  of  tin*  in/rrnrti('or/. 
/ranziai^ii'on  protocol. 
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CE*r  ANT)  KAHX:  PACKET  XETHORK  INTERCOMMUNICATION’ 

ADDRESS  FORMATS 

The  selection  of  address  formats  is  a  problem  between 
networks  becaa'»e  the  local  network  addresses  of  TCP’s 
may  var>’  substantially  in  format  and  size.  A  uniform  in¬ 
ternetwork  TCP  address  space,  understood  by  each 
GATPR’AY  and  TCP,  is  essential  to  routinf;  and  delivery 
of  internetwork  packets. 

Similar  troubles  are  encountered  when  we  deal  with 
proci'ss  addressing  and,  more  generally,  port  addressing. 
We  introduce  the  notion  of  porta  in  order  to  permit  a 
process  to  distinguish  between  multiple  mi's.sage  streams. 
The  port  is  simply  a  di'signator  of  one  such  message  stream 
associated  with  a  process.  The  means  for  identifying  a  port 
are  generally  different  in  different  operating  systems,  and 
therefore,  to  obtain  uniform  addn'ssing,  a  standard  port 
address  format  is  also  required.  A  port  address  designates 
a  full  duplex  message  stream. 

TCP  .\DDRESSING 

TCP  addressing  is  intimately  bound  up  in  routing 
issues,  since  a  host  or  (jateway  must  choose  a  suitable 
destination  host  or  gateway  for  an  outgoing  internetwork 
packet.  Let  as  postulate  the  following  addrc'ss  format  for 
the  TCP  address  (Fig.  4).  The  choice  for  network  identi¬ 
fication  (8  bits)  allow.s  up  to  2oG  distinct  networks.  This 
size  seems  sufficient  for  the  forsecable  future.  Similarly, 
the  TCP  identifier  field  permits  up  to  C.j  .">30  distinct 
TCP’s  to  be  addressed,  which  seems  more  than  sufficient 
for  any  given  network. 

As  each  packet  passes  through  a  gateway,  the  gateway 
observes  the  destination  network  ID  to  determine  how¬ 
to  route  the  packet.  If  the  destination  network  is  con¬ 
nected  to  the  GATEWAY,  the  lower  16  bits  of  the  TCP  address 
arc  ased  to  produce  a  local  TCP  address  in  the  destination 
network.  If  the  destination  network  is  not  connected  to  the 
GATEWAY,  the  upper  8  bits  are  used  to  select  a  subsequent 
gattwav.  We  make  no  effort  to  specify  how  each  in¬ 
dividual  network  shall  associate  the  internetwork  TCP 
identifier  with  its  local  TCP  address.  We  also  do  not  rule 
out  th(‘  possibility  that  the  local  network  understands  the 
internetwork  addres.sing  scheme  and  thus  alleviates  the 
GATEW’AY  of  the  routing  responsibility. 

PORT  ADDRESSING 

.\  receiving  TCP  is  faced  with  the  task  of  demultiplex¬ 
ing  the  stream  of  internetwork  packets  it  receives  and 
reconstructing  the  original  messages  f(»r  each  di'stination 
process.  Each  operating  system  has  its  own  internal 
means  of  identifying  processes  and  ports.  We  as-sume  that 
16  bits  are  sufficient  to  serve  as  internetwork  port  identifiers. 
A  sending  process  m<ed  not  know  how  the  destination 
port  identification  will  \m'  used.  The  d(*stinatioii  TCP 
will  b<’  able  to  pars'  this  number  apimipriately  to  find 
the  profM'r  buffer  into  which  it  will  place  arriving  p5ick«’ts. 
We  pi’rmit  a  large  |Mirt  number  field  to  sup|M>rt  pnio-ssi’s 
which  want  to  distinguish  between  many  different 
messages  stn'ams  concuirently.  In  r*ality,  we  do  not  car* 
how  the  16  bits  are  sliced  up  by  the  TCP’s  involved. 
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Fig.  4.  TCP  address. 

Even  though  the  transmitted  port  name  field  is  large, 
it  is  still  a  compact  external  name  for  the  internal  repre¬ 
sentation  of  the  port.  Th<*  us(*  of  short  names  for  port 
identifiers  is  often  di'sirabli*  to  reduce  transmission  over¬ 
head  and  possibly  reduce  {mckii  prs’i's.sing  time  at  the 
destination  TCP.  AKsigning  short  names  to  each  port, 
however,  mjuires  an  initial  negotiation  between  source 
and  destination  to  agree  cm  a  suitable  short  name  assign¬ 
ment,  the  subsequent  maint<*nance  of  conversion  tables 
at  both  the  source  and  the  destination,  and  a  final  trans¬ 
action  to  releasi*  the  short  name.  For  dynamic  assignment 
of  port  names,  this  negotiation  is  generally  neces.sary  in 
any  case. 

SEGMENT  AND  PACKET  FORMATS 

As  shown  in  Fig.  it,  messages  are  broken  hy  the  TCP 
into  segments  whose  format  is  shown  in  more  detail  in 
Fig.  6.  The  field  lengths  illustrated  are  merely  suggestive. 
The  first  two  fields  (source  port  and  destination  port  in 
the  figure)  have  aln-ady  been  diseussi'd  in  the  preceding 
section  on  addn'ssing.  The  uni's  of  the  third  and  fourth 
fields  (window  and  acknowledgment  in  the  figure)  will 
be  discussed  later  in  the  section  on  retransmUsion  and 
duplicate  detection. 

We  recall  from  Hg.  3  that  an  internetwork  header  con- 
tuns  both  a  sef|uence  number  and  a  byte  count,  as  well  aa 
a  flag  field  and  a  check  sum.  The  uses  of  these  fields  are 
explained  in  the  following  section. 

RE.\SSE.MBLY  AND  SEQUENCING 

The  reconstruction  of  a  message  at  the  receiving  TCP 
clearly  requires'  that  each  internetwork  packet  carry  a 
se<|uencc  number  which  is  uniiiue  to  its  particular  desti¬ 
nation  port  mi'ssage  stream.  The  s(><|uence  numbers  must 
be  monotunic  incn'asing  (or  di'cn'using)  since  they  arc 
used  to  reiirder  ami  n-assi'iuble  arriving  packets  into  a 
nn'ssage.  If  the  space  of  sequence  nuniht'rs  were  infinite, 
we  could  siniplx-  assign  the  next  one  to  I'ach  new  packet 
Clearly,  this  s|>ace  cannot  h<'  infinite,  and  we  w  ill  consider 
xvhat  problems  a  finite  seiiuenct'  nuinbi'r  space  will  cause 
when  we  discuss  n-transmission  and  duplicate  deti'ction 
in  the  next  si'ction.  We  propose  the  following  scheme  for 
performing  the  si'iiueiieing  of  {lackets  and  hence  the  re¬ 
construction  of  ini'ssagi's  by  the  di'stination  TCP. 

A  pair  of  |s»rts  will  ('xchange  one  or  more  messages  over 
a  period  of  time.  We  could  view  the  se<|uence  of  messages 
producf'd  by  one  |xort  as  if  it  weii'  mibeildi'd  in  an  in¬ 
finitely  long  streiiin  of  byt«*s.  I’jirh  byte  of  the  message  lias 
a  unique  se<|Ueiice  nuiiibt'r  wliieli  we  take  to  b<*  it-  bxte 
location  relative  to  the  Ix^giniiiiig  of  the  stream.  When  a 

•  In  ihf'  tti  enm-ptisl  packet-,  a  preltmiuKry  stage  of  re- 
Miembly  may  lie  reqiiimi  prior  tu  tits  rypuun. 
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Fig.  7.  Assignment  of  sequence  numbers. 


Fig.  C.  Segment  format  (prooes'  neader  and  text). 

M*pDcnt  is  extracted  from  the  mesaajte  by  the  source 
TCP  and  formatted  for  internetwork  tran.smiR.sion,  the 
relative  location  of  the  first  byt<*  of  Rcgment  text  is  ur'kI  aa 
the  Rotjuence  number  for  the  packet.  The  byte  count 
field  in  the  internetwork  header  accounts  for  all  the  text 
in  the  Rcgment  (but  does  not  include  the  check-aum  b>'te8 
or  the  bytes  in  cither  internetwork  or  process  header). 
We  emphasize  that  the  se(|ucnce  number  associated  vdth 
a  given  packet  is  unique  only  to  the  pair  of  ports  that  are 
communicating  (see  I'ig.  7).  Arriving  packets  are  ex¬ 
amined  to  determine  for  which  port  they  are  intended. 
The  sequence  numbers  on  each  arriving  packet  are  then 
used  to  determine  the  relative  location  of  the  packet  text 
in  th(’  messages  under  reconstruction.  We  note  that  this 
allows  the  exact  position  of  the  data  in  the  reconst ruett'd 
message  to  be  d<*t<*rmined  even  when  pieces  are  still 
missing. 

Every  segment  pn*duced  b\'  a  source  TCP  is  packag<<d 
in  a  single  internetwork  packet  and  a  chiH’k  sum  is  eom- 
puti-d  oviT  th<*  text  and  proce-<s  hi'adiT  associated  with  th<* 
segment. 

The  splitting  <»f  nn-ssag«‘s  into  wgments  by  the  TCP 
and  the  potential  splitting  of  segments  into  siaoller  pirns* 
by  (GATEWAYS  creatis  tin*  in*<*«-s.vity  for  indicating  to  the 
de-t illation  TCP  when  the  iTid  of  a  sigmeni  (ES)  has 
arrive*d  and  when  the  <*nd  of  a  im-ssage  (E.M )  ha>  arrivisl. 
The  flag  field  of  the  internetwork  header  i^  us*^!  f«ir  thi** 
purjMi-e  (ms*  I'ig,  S(. 

The  flag  ix  H*t  hy  the  Miun-e  TCP  «*ath  time  it  pn*- 
par<*s  a  M*gment  for  tran-nii-sion.  If  it  should  hapiwn  that 
the  nie-sage  i«  Complete))  eontaimsl  in  the  N'gment,  then 
the  E.M  flag  would  alMi  In-  m*i.  The  EM  flag  i?*  uImi  set  on 
the  lu*<t  M*gment  of  a  m«*’»N’ige.  if  the  message  could  not 
lx*  eontain«*d  in  one  segniene  Thi^se  two  flags  are  us»*d 
by  the  destination  TCP,  re^jss-tively.  to  discover  the 
pn-M-nee  of  a  ch«*<  k  sum  for  a  given  segment  and  todiscovi-r 
that  a  complete  message  ha-  arriv<*d. 

The  E.<  and  E.M  flag-  in  the  internetwork  header  are 
known  to  the«;ATfW  AV  am)  an*  of  -iM-f  ia)  im|Mirlanre  whc*n 
packet-  inu-t  Im*  -plit  apart  for  pmpagation  thmugh  the 
m*xt  l«K*al  network.  We  illustrate  their  um-  with  an  ex¬ 
ample  in  I'ig.  U. 

The  origins)  me*.-agi  .1  in  I'ig. i»  shown  split  into  two 
segment-  .ti  and  .4-  and  fom»att«*d  by  the  TCP  into  a  pair 
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Fig.  8.  Internetwork  header  flag  field. 
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of  intemetweirk  imeket-.  Packet-  A\  and  .1-  have  their 
I>  hits  wt.  and  .1-  ha-  it-  E.M  hit  -et  u-  well.  When 
l>ark(‘t  ,1|  pu-M*-  thmugh  tin*  «;ATi.nvAY,  it  i-  split  into  tw«i 
pi«*ces:  packet  .In  for  whieh  neither  E.M  rmr  ES  bit-  are 
set.  and  packet  .M:  who-e  ICS  bit  i-  s<*t.  .Similarly,  packet 
.1:  i-  split  Hueh  that  the  lir-t  pi«*ee.  packet  .l-i.  ha-  neither 
bit  si*t.  but  paf’ket  .1-  ha-  b<ith  bits  wt.  The  sequence 
numU*r  field  (SICQ)  and  the  hyte  count  field  (C'T)  of  each 
packet  i-  modilieil  by  the  f:AT>AVAV  to  pnqy'rly  itlentify 
the  text  byte-  <if  each  packet.  The  i;ateway  n«i*d  «inly 
examine  the  internetwork  h(*ader  to  do  fragmentation. 

The  d«*stimition  TCP.  ujmiii  rea-M‘inbling  segment  .Ij. 
will  detirt  the  ICS  flag  ond  will  verify  the  rh«*ck  -um  it 
know  s  is  coiitnineil  in  packet  .1,;.  l*pon  nreipt  of  packet 
An-  a— uming  all  other  packet-  have  arrivi-d.  the  d«*sti- 
iiatioii  TCP  (letift-  that  it  ha-  rea— cmbhil  a  complete 
nn-i-age  and  can  imw  ailvis**  the  destination  priK*«—  of  its 
receipt. 
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RETRANSMISSION  AND  DUPUCATE 
DETECTION 

No  transmission  can  be  100  percent  reliable.  We 
propose  a  timeout  and  positive  acknowledpnent  m'»cha- 
nism  which  \vt11  allow  TCP’s  to  recover  from  packet  losses 
from  one  host  to  another.  A  TCP  tran.smits  packets  and 
waits  for  replies  (acknowledgements)  that  are  carried  in 
the  reverse  packet  stresm.  If  no  acknowledgment  for  a 
particular  packet  is  received,  the  TCP  will  retransmit. 
It  is  our  expectation  that  the  host  level  retransmission 
mechanism,  which  is  described  in  the  following  para¬ 
graphs,  will  not  be  called  upon  vcr>*  often  in  practice. 
Evidence  already  exists*  that  individual  networks  can  be 
effectively  constructed  without  this  feature.  However,  the 
inclusion  of  a  host  retransmission  capability  makes  it 
possible  to  recover  from  occasional  network  problems  and 
allows  a  wide  range  of  host  protocol  strategics  to  be  in¬ 
corporated.  We  envision  it  will  occasionally  be  invoked  to 
allow  HOST  accommodation  to  infrequent  overdemands  for 
limited  buffer  resources,  and  otherwise  not  used  much. 

Any  retransmission  policy  require  some  means  by 
which  the  receiver  can  detect  duplicate  arrivals.  Even  if 
an  infinite  number  of  distinct  packet  senijence  numbers 
were  available,  the  receiver  would  still  have  the  problem 
of  knowing  how  long  to  remember  previously  received 
packets  in  order  to  detect  duplicates.  Matters  are  compli¬ 
cated  by  the  fact  that  only  a  finite  number  of  distinct 
sequence  numbers  are  in  fact  available,  and  if  they  are 
reused,  the  receiver  must  be  able  to  distinguish  between 
new  transmissions  and  rt'transmissions. 

A  window  strateg>‘,  similar  to  that  used  by  the  French 
CYCLSOES  system  (voie  virtuelle  transmission  mode  [s]) 
and  the  arfavet  ver>'  distant  host  connection  [IS], 
is  proposed  here  .(sec  Fig.  10) . 

Suppose  that  the  se<|uence  number  field  in  the  inters 
network  header  permits  sequence  numbers  to  rangf*  from 
0  to  n  -  1.  We  assume  that  the  sender  will  not  transmit 
more  than  w  bytes  without  receiving  an  acknowlislgnient. 
The  w  bytes  serve  as  the  window  (see  Fig.  11).  Cl<*nriy, 
w  must  be  less  than  n.  The  rules  for  m*nder  and  receiver 
are  as  follow  s. 

Sender:  Let  L  be  the  se<|uence  number  associated  %vith 
the  left  window  edge. 

1)  The  sender  transmits  bytes  fmm  s<-gments  whose 
text  lies  between  L  and  up  to  L  +  u?  -  1. 

2)  On  timeout  (duration  unsp<*cified).  the  sender 
retransmits  unacknowledged  hyti*s. 

3)  On  receipt  of  acknow li*dgment  consisting  of  the 
receiver's  current  left  window  edge,  the  sender’-*  left 
window  edge  is  advanced  ov  r  the  acknowledged  bytes 
(advancing  the  right  window  edge  implicitly). 

Reeeiter: 

1)  .\rriving  packets  whose  sr4|uence  numbers  eoincule 
with  the  receiver’s  current  left  window  i*dg«-  are  acknowl¬ 
edged  by  sending  to  the  situfc*--  the  next  s(s(uence  numb<-r 


643 


Lift  MmSow  ESa 


Fig.  10.  The  window  concept. 


F«.  11.  Conceptual  TCB  format. 

expected.  This  effectively  acknowledges  bytes  in  between. 
The  left  window  edge  is  advanced  to  the  next  sequence 
number  expected. 

2)  Packets  arriving  with  a  sequence  number  to  the  left 
of  the  window  edge  (or,  in  fact,  outside  of  the  window)  are 
discarded,  and  the  current  left  window  edge  is  returned  as 
acknowledgment. 

3)  Packets  whose  sequence  numbers  lie  within  the 
receiver’s  window  but  do  not  coinicide  with  the  receiver’s 
left  window  edge  are  optionally  kept  or  discanled,  but 
are  not  acknowledged.  This  is  the  case  when  packets  arrive 
out  of  order. 

We  make  some  observations  on  this  wcratcg.v.  First,  all 
computations  with  sis|uence  uuiiibf-rs  and  window  i-tlges 
must  be  made  nuxlulo  n  (e.g.,  byte  0  follows  byte  n  -  1 ). 
Secfind,  w  must  l»e  li-ss  than  n  '2*;  othenvis<*  a  n-tmns- 
mis-<ion  may  ap|»ear  to  the  n-ceiver  to  Is-  a  new  trans¬ 
mission  in  the  casi-  that  the  n-eeiver  has  accept*sl  n 
window’s  worth  of  incoming  packets,  but  all  aeknowh-dg- 
mimts  have  bi-en  lost.  Third,  the  n-ceiver  can  eitlier  s:ive 
or  discard  arriving  (lackets  wlnsx-  M-4|uence  nuinlM-rs  do 
not  coincide  with  the  n-ceiver’s  left  window.  Thus,  in  the 
simplest  implementation,  the  n-eeiver  m-ed  not  bnlb-r 
nwre  than  one  |iacket  fs-r  message  stn-am  if  s|>:ue  i<* 
critical.  Fourth,  inuhiple  packets  can  Is-  acknowhslgi-tl 
siinultanistusly.  1-lftb.  tin-  n-e«-ivrr  is  ,-d»le  t«>  deliver 
nn-ssagt-n  to  pns-esM-!*  in  their  pn*|s*r  order  as  a  natural 
result  of  the  nu-^smbly  iiK-clianisin.  J^ixth,  when  dupli¬ 
cates  an-  det«s-te»l.  the  ackliowhslgnielit  niethisl  us«sl 
natunilly  works  t«>  n-synebronixe  M-iuh-r  and  n-ceiv«-r. 
Furthemmn-.  if  the  n-e«-iv«-r  an-epts  iKickets  wIio-m* 
!M-qnence  iniiiils-rs  lie  within  the  current  window  Init 


*  Th*  aRFaskt  i»  one  »urh  cx/<mpir. 


*Ai-tii»ily  s  2  U  toerrix  •  iinivriiirtit  Muniltcr  l'»  it  o  miiIv 
nsluirtti  thiu  a  retnui-im— i«*«  imi  Mpiwiu  l»*  Isr  »  <Mrs 
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which  an*  not  coincident  intli  the  left  window  edge,  an 
acknowledgment  consisting  of  the  current  left  window 
edge  would  act  as  a  stimulus  to  cause  retransmission  of  the 
unackitowledgcKl  bvies.  Finally,  we  mention  an  overlap 
problem  which  r(*sults  fnun  n^transmission,  packet 
splitting,  and  alternate  routing  of  packets  through  dif¬ 
ferent  gateways. 

A  COO-byte  packet  might  pass  through  one  catiway 
and  be  broken  into  two  :i00-byte  packets.  On  retrans¬ 
mission.  the  same  packet  might  be  broken  into  three 
200-byte  packets  going  tlmiugh  a  different  gatiway. 
Since  each  byte  has  a  setpience  number,  there  is  no  con¬ 
fusion  at  the  receiving  TCP.  We  leave  for  later  the  issue 
of  initially  synchronizing  the  sender  and  receiver  left 
window  edges  and  the  window  size. 

I’LOW  CONTROL 

Even-  segment  that  arrivis  at  the  destination  TCP  is 
ultimately  aeknowleilged  by  returning  the  sequence 
numb<*r  of  the  next  s«*gment  which  must  be  passed  to  the 
process  (it  may  not  yet  liave  arrived ) . 

Earlier  we  described  the  uw  of  a  se(|uenee  number 
space  and  wind<«w  to  aid  in  duplicate  dei<*ction.  Ac¬ 
knowledgments  are  carried  in  the  process  header  (see 
Fig.  G)  and  along  with  them  there  is  provision  for  a 
“suggested  window*’  which  the  receiver  can  use  to  control 
the  flow  of  data  from  the  sender.  This  is  intendt'd  to  be 
the  main  comp‘inent  of  the  process  flow  control  mecha¬ 
nism.  The  HTeiver  is  free  to  vary  the  window  site  accord¬ 
ing  to  any  algorithm  it  d<*sin‘s  s<i  long  as  the  window- 
size  never  exceeds  half  the  se(|uence  number  space.* 

This  flow  control  tniThanism  is  exceedingly  isiwerful 
and  flexible  and  d«»es  not  suffer  from  synchronization 
trouhh*s  that  may  Is*  eneountCiX'd  by  incir»*mental  buffer 
allocation  schem«‘s  [y].[10].  However,  it  relies  heavily 
on  an  effectiv.*  retransmission  strat«*g.v.  The  r«*ceiver  can 
n-duei-  the  window  even  while  itackets  are  en  n«ute  fmm 
the  wilder  whosi-  window  is  pnsMiitly  larger.  The  net 
eff«*et  of  thi^  reduction  will  b<*  that  the  receiver  may 
discard  incoming  packets  (they  may  be  outside  the 
window  I  and  reiterate  the  eum*nt  window  size  along  with 
a  eumut  window  islge  as  acknow|<slgni<‘nt.  By  the  same 
token,  the  sender  ran.  u|sin  tsTasion.  cIhs»w  to  wnd  mon* 
than  ft  window  -  worth  of  data  on  the  |M»-sil>ility  tliat  the 
nf  oiY'i-r  will  expand  the  window  to  accept  it  (of  course,  the 
M*nder  inu-t  not  M>nd  more  than  half  the  wsiuerice  nunilx'r 
space  at  any  time).  Nonnally.  we  would  ex|s*ct  the  sender 
to  abide  by  the  window  limitation.  l'h(|iansion  of  the 
window  by  the  ns-eiver  ineri-ly  allows  more  data  to  lie  ac- 
reptisl.  For  the  ns-eiving  most  with  a  small  amount  of 
buffer  s|ia<-.  a  -irati*g\-  of  diseanling  all  p.nck«*ts  wlio-e 
se«|uenee  nunilx*r>  do  not  (*oineide  with  the  rumiit  left 
lilgeof  the  window  i-  proliably  iii’ci'— ary.  but  it  will  incur 
the  exis-n-Mnf  extra  delav  and  overhead  for  retraii-mi— 
sion 


TCP  IXPUT/OUTPUT  HANDLING 

The  TCP  has  a  component  which  handles  input /output 
(I/O)  to  and  from  the  network.*  When  a  packet  has  ar¬ 
rived,  it  validat<*s  the  addri's.sis  and  plac<*s  the  packet 
on  a  <iueu<*.  A  p<Kil  of  buffers  can  be  s(*t  up  to  handle 
arrivals,  and  if  all  available*  buffers  are  used  up,  succe‘<‘ding 
arrivals  can  be  discarutd  since  unacknowledged  packets 
will  be  retransmitted. 

On  output,  a  smaller  amount  of  buffering  is  needed, 
since  process  buffers  can  hold  the  data  to  be  transmitted. 
P(‘rhaps  doubh*  buffering  will  b<*  ade()uate.  We  make  no 
attempt  t<i  s|x*cify  how  the  buffering  .should  lx*  done, 
except  to  r<‘<|uir«*  that  it  b<*  able  to  wrvice  the  network 
with  as  litth*  overhead  as  ixissible.  Packet  mzinI  buffers, 
one  or  mon*  ring  buffers,  or  any  other  combination  are 
pos,<ible  candidat(‘s. 

Wh<*n  a  pack(*t  arrives  at  the  destination  TCP,  it  is  placed 
on  a  queue  which  the  TCP  services  fnxiuently.  For  ex¬ 
ample,  the  TCP  could  be  int(‘rrupt(*d  when  a  <|ueu<*  place¬ 
ment  occurs.  The  TCP  then  attempts  to  place  the  packet 
text  into  the  pmper  place  in  the  appropriate  process 
receive  buffer.  If  the  ixicket  terminates  a  segment,  then 
it  can  Ik*  checksuninn*d  and  acknow  !f*dg<*d.  Placement 
may  fail  for  several  reasons. 

1)  The  di*stination  pnK*«*ss  may  not  be  prepared  to 
receive*  from  the  stated  source,  or  the  di'stination  jxirt  ID 
may  not  exist. 

2)  There  max-  Ik*  insufficient  buffer  space  for  the*  text. 

3)  The  he*ginning  s<*e|ue*nce*  numlK*r  of  the  text  ina  * 
neit  coincide  with  the*  next  se*eiue*iice  numlier  to  Ik*  de*live*re'd 
to  the  pr«ce*ss  (e.g.,  the  jiacket  has  arrived  eeut  e»f  orde*r). 

In  the  first  case,  the  TCP  slntuld  simply  discard  the 
packet  (thus  far.  no  pmvisiem  has  be*en  made*  for  ermr 
acknowledgments).  In  the*  second  and  third  case*s.  the 
packet  se<|uence*  number  can  be*  inspect »d  tei  de*t ermine 
whether  the  packet  te*xt  lie's  within  the*  l<*gitiu)ate*  wind««w 
fe»r  n*ception.  If  it  dess,  the*  TCP  may  eiptieiiially  ke*<*p  the 
packe*t  e|ue*ue*el  feir  later  pMcessing.  If  in*t.  the*  TCP 
can  discard  the*  |)acke*t.  In  e*ithe*r  case*  the*  T('P  can 
uptieinally  ae-kneewledge  xvith  the*  ciirre*nt  le*fi  window  edge*. 

It  may  b:ip|M*n  tluit  the*  pMee*s«i  n*ce*i\'i-  buffe-r  i-  met 
pri'seiit  in  the*  active*  me*ine*rv  iif  the*  iieesT.  but  is  -teire*el  on 
sifeindary  steerage*.  If  this  i-  the*  e*nse*,  the*  TCP  can  preempt 
the*  schedule*r  to  bring  in  the*  npprteprinte*  liuffe*r  and  the* 
|tacke*t  can  Is*  e|ue‘Ued  feer  late*r  pres'i'ssing. 

If  the*n*  an*  im  nieen*  input  buffe*rs  available*  tei  the-  T('P 
feer  te*m|senir>-  e|ue‘Ue*ing  eef  ineteining  p;icke*ts.  anel  if  the* 
TCP  e*anneet  i|uirkly  use*  the*  arriving  data  (e*.g..  a  T(’P 
tee  TCI*  nwssHge*).  the*ii  the*  |»;ie*ke*t  is  disi*ar<le*el.  .\s4nniing 
a  se*nsibly  functieening  s>>te*in.  ne»  othe*r  pns-f— e*s  iban  the* 
eilie*  for  which  the*  |iacke*t  was  inteaieled  slieeejhl  Is*  ,lffi*Cte*el 
by  this  disi-arding.  If  tin-  di-laxed  presN-tsing  e|Ue*ne*  gnews 

'The-  otMiurttrett  «i%ei  ■e'nrt*  l»  le.-iiHlIi*  uIIict  preS***’,*!- 
iVM-  ulrU  iitKirul  leoiariUii-  :iir  iti-ei:*i.*e«*«l  !•>  enleriiirlwiirk  ilf-leeia- 
liitet  Ailtirr— 
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exccRsivoly  long,  any  packotn  in  it  can  bo  safely  discarded 
since  none  of  them  have  yet  been  acknowledged.  Con¬ 
gestion  at  the  TCP  level  is  flexibly  handled  owing  to  the 
robust  retransmission  and  duplicate  detection  strategy’. 

TCP/PROCESS  COMMUNICATION 

In  order  to  st'nd  a  ines.sage,  a  protvns  .".et"  up  its  text 
in  a  buffer  region  in  it.s  own  address  space,  inserts  the 
requisite  control  information  (described  in  the  following 
list)  in  a  transmit  control  bltjck  (TCB)  and  paws  control 
to  the  TCP.  Tlie  exact  form  of  a  TCB  is  not  specified 
here,  but  it  might  take  the  form  of  a  pas.s<'d  pointer,  a 
pseudointerrupt,  or  varioas  other  forms.  To  receive  a 
mes.sage  in  its  address  space,  a  process  sets  up  a  receive 
buffer,  inserts  the  requisite  control  information  in  a 
receive  control  block  (RCB)  and  again  passes  control 
to  the  TCP. 

In  some  simple  systems,  the  buffer  space  may  in  fact 
be  provided  by  the  TCP.  For  simplicity  we  assume  that 
a  ring  buffer  is  used  by  each  process,  but  other  structures 
(e.g.,  buffer  chaining)  are  not  ruled  out. 

A  possible  format  for  the  TCB  is  shown  in  Fig.  11.  The 
TCB  contains  information  necessary  to  allow  the  TCP 
to  extract  and  send  the  process  data.  Some  of  the  informa¬ 
tion  might  be  implicitly  known,  but  we  are  not  concerned 
>\’ith  that  level  of  detail.  The  various  fields  in  the  TCB 
are  described  as  follows. 

1 )  Source  Addreu:  This  is  the  full  net  host  'TCP /'port 
address  of  the  transmitter. 

2)  Detunotion  Addreu-  This  is  the  full  net 'host' 
TCP  'pf>rt  of  the  rectnver. 

.1)  XexI  I*nekei  Sequence  X umber-  This  is  the  seejuence 
number  to  be  used  for  the  next  packet  the  TCP  will 
transmit  from  this  port. 

4)  Current  Buffer  Size:  This  is  the  pre^’iit  site  of  the 
pr«»eess  transmit  buffer. 

.*i)  Xr/t  HVi/e  l*tnilmn-.  Thi>*  i-  the  address  of  the  next 
{M>-ition  in  the  buffer  at  whieh  the  pns'i^ss  ran  pinee  new 
data  for  transmission. 

(i)  Xf/l  Bead  Cosilum:  Tliis  is  the  nddri‘»-  .it  whieh  the 
TCP  should  b<*gin  reading  to  build  the  next  •s-gment  for 
output. 

7)  Bnd  Heod  Bosilion:  This  is  the  addn*s-  at  which  the 
TCP  should  halt  transmission.  Initially  li)  and  7)  Isiund 
the  message  whieh  the  prsvss  wishist  to  transmit. 

.S)  X umber  of  RelrnnsmittmnM  Mo/imum  /fiiruinmit- 
Tliese  fields  enable  th«*  T(*P  to  kis*p  track  id  the 
number  i»f  times  it  has  retransmittisl  the  data  and  could  Ik* 
omitted  if  the  TCP  is  not  to  give  up. 

0)  Timritut ' Ftnq»:  The  tiiuisiut  Held  sp«>cilies  the 
delay  after  which  unaekimwlislgnl  diita  shoiihl  U*  n’trans. 
mittisl.  Tlie  flag  field  is  usisl  for  s4*iuapliores  and  other 
TCP  prmess  svnchroniz;ition,  status  n'tstrting.  etc. 

10)  ('uircnt  ArLnmHtdgmt  nt  Wtmlmr:  llie  current 
aeknowltslgmeiit  field  identifies  the  first  hvte  of  data 
still  unacknowhsiged  h\  the  di'stiiiation  TCP. 
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The  read  and  write  positions  move  circularly  around  the 
transmit  buffer,  with  the  write  position  always  to  the  left 
(module  thi*  buffer  size)  of  the  read  position. 

The  next  packet  sequence  number  should  bi*  constrained 
to  be  less  than  or  ef|ual  to  the  sum  of  the  current  ac¬ 
knowledgment  and  the  window  fields.  In  any  event,  the 
next  sc<|uenee  number  should  not  excisd  the  sum  of  the 
current  ackno\Tii*dgment  and  half  of  the  maxfnTQm  possible 
sequence  numlK*r  (to  avoid  confusing  the  receiver's 
duplicate  detection  algorithm).  A  possible  buffer  layout 
is  .shown  in  Fig.  12. 

The  RCB  is  substantially  the  same,  except  that  the  end 
read  field  is  replaced  by  a  partial  si*gment  check-sum 
register  which  jiermits  the  receiving  TCP  to  compute  and 
remember  partial  check  sums  in  the  event  that  a  segment 
arrives  in  several  packets.  When  the  final  packet  of  the 
segment  arrives,  the  TCP  can  verify  the  cheek  sum  and  if 
succewful,  acknowledge  the  segment. 

CONNECrriONS  AND  ASSOCI.XTIONS 

Much  of  the  thinking  about  process-to-process  com¬ 
munication  in  packet  switched  networks  ha.s  been  in¬ 
fluenced  by  the  ubiquitous  telephone  system.  The  host- 
host  protocol  for  the  arp.wet  deals  explicitly  with  the 
opening  and  closing  of  simplex  connections  between 
processes  [9].[10].  Evidence  has  bis*n  pn'sented  that 
message-based  "coniiection-fn'i*”  pn»tocols  can  bi*  con¬ 
structed  [12],  and  this  leads  us  to  carefully  ex.iniine  the 
notion  of  a  connection. 

The  tenii  nmneeliuH  has  a  wide  variety  of  meanings.  It 
can  refer  to  a  physical  or  logical  path  lK*twi*en  two  en- 
titii*s.  it  can  refer  to  the  flow  over  the  path,  it  can  in- 
fen  ntially  refer  to  an  action  assiM'iuted  with  the  'getting 
up  of  a  path,  or  it  can  refer  to  an  a— is-iation  In'twirii  two 
or  inon*  entith"*.  with  or  without  rii::inl  t<i  any  path 
bi'twemi  them.  In  thi-  pa|K*r.  we  do  not  explieitly  ri’ject 
■he  tenn  conni'ctioii.  -iiice  it  i-  in  >iich  widespread  u.*e. 
and  ihs*-  eonno|i>  ;i  meaningful  rehilioii.  but  roii-ider 
it  exclusively  in  the  <.rn-c  of  an  a— oei;iiit<n  lK*twei*n  two  or 
niori*  entities  without  ri'g:ird  to  a  iKitli.  To  Is*  more  precise 
alsillt  our  illlent.  we  -ball  define  tbe  rehltioll-llip  betwiM*! 
two  or  nion*  jsirt-  tb:it  an*  in  eomnnmieation.  or  an*  prt*- 
pan*d  to  communicate  to  Is*  an  utsueiotmn.  Port-  tliat 
are  assi>ciat«*<i  with  «*:icli  other  an*  calh*<l  imueiutrt. 

It  is  clear  that  for  any  eomniuuieation  to  take  place 
betwi*en  two  pnH*i‘s'*i*-.  om*  mu.-t  Is*  able  to  addn*—  the 
other.  The  two  imts<rtant  ca-<*s  ben*  an*  tliat  the  di*-ti- 
nation  tK>rt  piay  have  a  global  and  unchanging  addn*—  or 
tliat  it  may  U*  globally  unique  but  d>  namirally  n*a— ignitl. 
While  ill  •*itber  ea-s*  the  siauli'r  may  have  to  learn  the 
destination  addn*—.  given  the  de-tiiiation  nanu*.  only  in 
the  !-<*cond  in-tanee  i-  iben*  a  n*«|’inn*ment  for  h*arning  the 
addn*—  fn«m  the  dt**>tination  (or  it-  n*pn‘-<*ntativ«*t  each 
time  an  a— 4s*iation  i-  de^intl.  thdv  after  the  -«ium*  Iul- 
|eanii<«l  how  to  addn—  tin*  de-tinaiioii  can  un  a-*-‘cbtiou 
Ik*  ^id  to  have  •K-cnrn**!.  But  ihi>  i-  not  yet  -uffich*iit.  If 
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Fif .  12.  Transmit  buffer  layout. 

•  ^ 

ordering  of  delivered  iiieRsages  is  also  desired,  both 
TCP’s  must  maintain  sufficient  informatifin  to  allow 
proper  setjueiicing.  When  this  information  is  also  present 
at  both  ends,  then  an  as<ociation  is  said  to  have  occurred. 

Note  that  we  have  not  said  anything  about  a  path,  nor 
anything  which  implies  that  either  end  b<‘  aware*  of  the* 
condition  of  tlie  other.  v>nly  when  both  partners  are 
prepanKl  to  cejmniunicate  with  each  other  has  an  associ- 
atiem  eiccurred,  and  it  is  jvisrible  that  neither  partner 
may  lx*  able  to  ve-rify  that  an  assejciatiein  exists  until  some 
data  flows  between  them. 

COXXECTIOV-FUEE  PROTOCOLS  WITH 
ASSOCI.\TIOXS 

In  the*  ARPANET,  the  interface*  mes.sage  processors 
( imp’s)  do  not  have  to  e»pen  and  close  connections  from 
source  to  destination.  The  reason  for  this  is  that  con« 
ne*ctiun*‘  are*,  in  cffee*t,  always  eipen.  since  the  address  of 
eve*ry  source  and  de*stination  is  never*  reas.signe*d.  Whe*n 
the  name*  and  the*  place*  an*  static  and  unchanging,  it  is 
only  neces.sar>'  to  laliel  a  packet  with  source  and  de*sti- 
natiem  to  transmit  it  through  the  network.  In  our  parlance, 
cve*r>’  source  and  de*stination  forms  an  association. 

In  the  case  of  pnicesses,  hoAvever.  we  find  tliat  port 
addrt*sHe*s  are  cemtiiiually  being  used  and  reus<*d.  Some 
e\*er-pn*seiit  proce*sscs  could  be*  assigned  fixed  address<*s 
which  do  not  change*  (e  g.,  the*  lugger  process).  If  \\  v  sup¬ 
posed,  he»weve*r,  that  every  TCP  had  an  infinite  supply  of 
port  addre*s«c«  so  that  iiee  e»ld  addn*ss  w  ould  ever  be*  reused. 
the*n  any  dynamically  ere*ated  jsirt  would  be  assiguiti  the 
n(*xt  unuse-d  address.  In  such  an  e*iivirunnient,  there 
cuuld  fM*ve*r  be*  any  confusion  by  source  and  de*stination 
TCP  as  to  the  inte*nde'd  n*eipie*nt  ejr  implie<d  source*  e»f  each 
ni<*ssag<*.  and  all  fvirts  would  be*  associate's. 

Vnfeirtunately,  TCP’s  (ejr  more*  pro|»e*rly.  e»pe*rating 
syste-nis )  te*nd  not  to  have*  an  infinite*  supply  of  inte*mal 
|Hjrt  addn*sst*s.  Tlu*s«*  inte*r!ial  addn*sses  an*  n*assigne*d 
aft(*r  the*  demise*  of  e  ach  jstrt.  Walde'n  [12]  suggests  that 
a  se*t  of  unieiue*  uniform  external  |M>rt  addrrss(*s  could 
be  supplie*d  by  a  C(*ntral  rt*gistry.  A  nenily  cr(*ate'd  |Mirt 
could  apply  to  the  ci*ntral  registry  for  an  addrr**s  which 
the*  rf*ntral  n-gisiry  weiuld  guarantei*  tee  be*  unuse*d  by  any 
MOST  s>stem  in  the*  ni*twu:k.  Each  TCP  ceiuld  maintain 
table's  matching  e*xte  rnul  naine*s  with  inte*mal  oiie*s.  and 
use*  the  e*xt**rnal  tene*s  fe»r  e'oimnunication  with  othe-r 

*  Vslr—  ihr  IMP  e*  physerallv  mueevd  tu  amKhr?  set*,  ur  tke^ 
MOST  e«  loitdrtirsi  t.*  m  I.MP 


processes.  This  ide*a  violates  the*  premise  that  interprocess 
ceimmunicatiem  should  not  r(*e|uire  centralized  cemtrol. 
One  would  have  to  extend  the  ce*ntral  registr>'  service*  to 
include  all  Hei.sT’s  in  all  the  intereonne*cted  networks  to 
apply  this  ide*a  to  eiur  situation,  and  we  the*re*fe)re  do  not 
atte*mpt  tei  adopt  it. 

Let  us  cemsider  the  situatiem  freini  the  standpoint  of  the 
TCP.  In  order  to  send  or  receive  data  for  a  given  pejr», 
the  TCP  ne'cds  to  set  up*a’TCB  and  RCB  and  initialize 
the*  window  size*  and  left  window  e*dg<*  feir  both.  On  the 
rece*ive  side,  this  task  might  e*ve*n  be*  de*laye*d  until  the 
first  packet  de*stined  feir  a  given  |X)rt  arrive*s.  By  con- 
V(*ntioii,  the*  first  pae*ke*t  should  1m*  marke*d  sej  that  the 
re*ce*ive*r  will  sx  nchroiiize*  to  the  re*ce*ive*d  seeiue*nce  number. 

On  the*  send  side*,  the*  first  re*ejue*st  to  transmit  could 
cause*  a  TCB  to  Im*  se*t  up  with  se»me*  initial  se*e|uence* 
number  (say,  zero)  and  an  assume*d  windeiw  size.  The 
receiving  TCP  can  reject  the  packe*t  if  it  wishe*s  and 
neitify  the  se*nding  TCP  of  the  corre*ct  window  size  via  the 
acknuwle*dgme*nt  mechanism,  but  emly  if  either 

1 )  \ve  insist  that  the  first  packet  be  a  complete  segment ; 

2)  an  ackneiwledgment  can  be*  s<*nt  feir  the  first  packet 
(even  if  not  a  segment,  as  hmg  a*  the*  acknowledg¬ 
ment  specifies  the  next  s«*i|ue*nc(*  number  such  that 
the  source  also  understands  that  no  bytes  have  been 
accepted). 

It  is  apparent,  therefore*,  that  the  synchronizing  eif  window- 
size  and  l(*ft  window  edge  can  be  accomplishe'd  withoi  *. 
what  would  ordinarily  be*  called  a  ce>nne*ctioii  setup. 

The  first  pack(*t  ref(*rencing  a  nc'.vly  cr<*ated  RCB 
s«*nt  from  one  associate  to  another  can  be  markt*d  with  a 
bit  wluch  ree^uests  that  the  receive*r  synclmenize*  his  h*ft 
windoxv  edge*  with  the  se<|uenee  number  of  the  arriving 
packet  (see*  SYX  bit  in  Fig.  8).  The  TCP  can  examine  the 
source  and  destination  port  addresses  in  the  packet  and 
in  the  RCB  tf)  decide  whether  U<  accept  or  ignore  the 
request. 

Provision  should  L*  made  for  a  destination  prtnCT**  to 
sp<*cifv  that  it  i«  willing  to  listen  to  a  sjM*cific  port  or 
“any”  port.  Tlus  last  idea  pennit^  pn>ce**t*s  such  as  the 
logger  process  to  acc«*pl  data  arriving  fn«m  unsjM*cirM<d 
s<»urc<*s  This  iti  puniy  a  most  matter,  however. 

The  initial  packet  may  contain  data  which  can  Im*  stored 
or  discarded  by  the  dfsitinatioii.  de|>«*i)ding  on  the  avail¬ 
ability  of  d<*stinati*>n  buffer  «|>an*  at  the  time.  In  the  other 
dir(*ction.  acknowii'dgment  is  n*tunM*d  for  renipt  of  data 
which  al-si  specifM*s  the  rt*reiver’s  window  size. 

If  the  receiring  TCP  sLiuld  want  to  rej(*ct  the  syn- 
chnmization  r«s|uest,  it  ineHy  tmnsinitA  an  acknowh'dg* 
ment  carry  ing  a  releam*  (RKiJ  bit  Hg.  S)  indicating 
tliat  the  di*stinatirm  imn  addn-<'  i*  unknown  or  inact*«**- 
sible  Thi*  si'iiding  most  waits  f*ir  the  ackno-«ik }(<dgment 
(after  aei-epting  or  n*j«Tting  the  -x nchronization  request) 
Is'fon-  •M'liding  the  in-xt  message  or  si-gtnent.  Tin*  rejection 
I-  quite  diffen*nt  from  a  n<*gntivi*  dat.*t  acknowlixlgnient. 
We  do  not  have  explicit  iM*gative  urkn**wh*dgn>cnts  If  nt« 
arknowledginent  is  n-tunied.  the  «<*ndiiig  Most  max 
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retransmit  without  introduciiiK  confusion  if,  for  example, 
the  left  window  edge  is  not  ehnnged  on  the  retransmission. 

B«>caus<>  ni4*ssnges  may  b<*  hraken  up  into  many  packets 
ftir  traiisinissioii  or  duriiiK  transmission,  it  will  be  nw's- 
sary  to  ignon*  the  IIKL  flag  except  in  the  case  that  the 
E.M  flag  is  also  S4*t,  Tliis  eould  b<*  accomplished  either 
by  the  TCP  or  by  the  gateway  which  eould  n‘set  the  flag 
oil  ail  but  tile  iiaekei  containing  the  set  EM  flag  (siv 
Fig.  0). 

.\t  the  end  of  an  ass«*eiation,  the  TCP  sends  a  jvieket 
with  ES,  E.M,  and  PEL  flags  si*t.  The  packet  se<|uence 
nuinlxT  scheme  will  .alert  the  ret-eiving  TCP  if  there  are 
still  outstanding  packets  in  transit  which  have  not  yet 
arrived,  so  a  pnanature  diss4»eiation  cannot  occur. 

Tt*  as.4ure  that  l)»»th  TCI*'s  an*  awan*  that  the  associ¬ 
ation  lias  end(*d,  we  insist  that  the  receiving  TCP  res|)ond 
to  the  REL  by  sending  a  REL  acknowledgment  of  its 
own. 

Suppose  now  that  a  pnxx'ss  sends  a  single  message  to  an 
associate  including  an  REL  along  with  the  data.  Amuming 
an  RCB  ha.s  been  prepart*d  for  the  receiving  TCP  to 
accept  the  data,  the  TCP  will  accumulate  the  incoming 
packets  until  the  one  marked  ES,  EM.  REL  arrives,  at 
which  point  a  REL  is  returned  to  the  sender.  The  associ¬ 
ation  w  thereby  terminated  and  the  appropriate  TCB 
and  RCB  are  destroyed.  If  the  first  packet  of  a  message 
contains  a  SYX  request  bit  and  the  last  packet  contains 
ES.  E.M,  and  REL  bits.  th<*n  data  will  flow  “one  message 
at  a  time.**  This  mode  is  ver>‘  similar  to  the  scheme  de¬ 
scribed  by  Walden  [12].  since  <*ach  succeeding  message 
can  only  be  accepted  at  the  r«*ceiv<‘r  after  a  new  listen 
(like  Walden’s  receive)  command  is  issued  by  the 
receiving  process  to  its  serving  TCP.  Note  that  cmly  if  the 
acknowh«dgmcnt  is  receivr'd  by  the  sender  can  the  associ¬ 
ation  be  terminated  prr^rly.  It  ha.s  been  pointed  out* 
that  the  receiver  may  erroneously  accept  duplicate 
transmisMtms  if  the  sender  disn  not  receive  the  acknowl¬ 
edgment.  This  may  happen  if  the  sender  transmits  a 
duplicate  message  with  the  SVN  and  REL  bits  set  and  the 
destiruition  has  already  destroyed  any  record  of  the 
previous  transmission.  One  way  of  pn'ventiiig  this  pr<»blem 
is  to  destroy  the  record  of  the  assneiation  at  the  doti- 
nation  only  after  sume  kmiwn  and  suitably  ch*>sm  timeout. 
Howrarr.  this  impli<*s  that  a  m*w  association  with  the 
same  source  and  d<*stiiiation  p>>rt  id<*titiliers  could  not  be 
establish«*d  until  this  timeout  had  4*xpired.  This  pr«>hlem 
can  ticcur  even  with  s«s|U«*tinsi  <•!  iiM*'»agf's  whtMi*  SYN 
and  REL  bits  an*  M’fiarati'd  into  ditTeniit  iniemetwork 
packets.  We  n'cognixe  that  ihi«  |ir>4ilem  must  bi*  siflv<*d. 
but  d<i  mit  go  into  furthti*  d<*tail  Hen*. 

.\lti*mativi*ly.  bi»th  fimeisisi**  can  send  •me  nn-ssogr. 
causing  th«*  re«{s*cti\e  TCP’-  iti  alhs*aie  RCU  TCB 
pair*  at  Isith  end*  which  nmlei^nu*  with  the  exrhangisl 
data  and  tln*n  disappi'or.  If  tin*  overin-ad  of  cnaiting  and 
dts>tn»ying  RCU's  and  TCU’s  is  small,  such  a  |>n>t«s*t»l 


647 

might  be  ade<|uate  for  most  low-bandwidth  u.ses.  This  idea 
might  also  form  the  baisis  for  a  n*Iatively  secure  trans- 
mis.sion  system.  If  the  communicating  pnicesses  agree  to 
change  their  c*xternal  p«»rt  addn*ss«*s  in  winn*  way  known 
only  to  each  other  (i.e.,  |»s<*iid4»random),  then  4*ach 
nies.sag<'  will  apis  ar  to  the  outside  world  as  if  it  is  part  of  a 
diffen*nt  a.s.sociati‘»n  nw's.'mge  stn*am.  Even  if  the  data  is 
intercepted  by  a  third  party,  he  will  have  no  way  of 
knowing  that  the  data  sh«»uld  in  fact  be  considered  part  of 
a  .sequence  of  mi‘ssages. 

We  have  d<*scrib<*d  the  way  in  which  pn>«*s.s4*s  develop 
asstwiations  with  eaeh  other,  then*bv  becoming  ns.s4K*iates 
for  fsissibh*  exchange  of  data.  Thi‘s<*  associations  need  not 
inviJve  the  transmission  of  data  prior  to  their  formation 
and  indfs-d  tw»»  as.siK*iatfs  iws-d  m»t  Is*  able  to  d4*termine 
that  they  an*  assnciati*s  until  thf'V  attempt  to  communi¬ 
cate. 

CONCLUSIONS 

We  have  discussi'd  some  fundamental  issues  related  to 
the  interconnection  of  packet  switching  networks.  In 
particular,  wc  have  described  a  simple  but  V4*r>-  p*»wc*rful 
and  flextb!'*  prot'.'C**!  which  nn*vides  for  variation  in 
individual  network  packet  sites,  transmission  failun*s, 
sequencing,  flow*  contnil,  and  the  creation  and  destruction 
of  process-to-process  associations.  We  have  considered 
some  of  the  implementation  issues  that  arise  and  found 
that  the  proposed  protocol  is  implementable  by  host’s 
of  widely  vaiying  capacity. 

The  next  imptirlant  step  is  to  pniduce  a  detailed  speci¬ 
fication  of  the  protocol  so  that  some  initial  exp(*riment« 
with  it  can  be  performed.  These  experiments  are  needed 
to  determine  some  of  the  operational  parameters  (e.g., 
how*  often  and  how*  far  out  of  order  do  packets  actually 
arrive;  what  sort  of  delay  is  tliere  between  segment 
acknowhdgments;  what  should  be  retransmission  time^ 
outs  be?)  i»f  th**  proposed  protoetd. 
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Issues  in  Packet-Network  Interconnection 
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Abtirmri-Thk  pepm  iiicrod«cw  dM  wtd«  nmpt  oT  tKfcakai,  Upt. 
poUtkal  imnm  emodetei  widi  dM  iulMOoiiiMclkM  oi  pckt^ 
twttdl*J  <1«U  ooMOHudcatioa  MtMrlU.  ModvsdoM  fov  tetmoMMC- 
do*  pvtK  dedsnd  ween  mniem  me  tecrilMd,  ud  «  nN|t  of  tsdi- 
Micd  cJkmmi  for  •chirriftf  MlMcowMCtto*  an  coai|Mi«d.  bw«  mmk 
m  dM  Ural  of  tetMcouMcdcw.  dM  ratt  oT  ptewijrt,  mmm|  aad 
eddremim^  (lot*  aad  coagwdM  eoacrol.  accoviiciiif  uM  KoaMCMOct. 
m4  buk  wtcnMt  icmcw  an  diacnawM  im  detdL  TW  CCTTT  X.25I 
X75  pckaf-iMtwwk  inlavfaca  racomoMadaCtoM  an  rratiulad  iii  lanM 
at  dMM  atpOcabitity  to  aat^iwk  iatanoaiMCttoa.  AtMniaitvai  meek  at 
data^M"  opnuoa  and  fraenJ  kott  ptrrayi  an  compand  •ilk  dM 
lirTiiai  dnatl  mcdiodi^  Sana  oCaarvadoat  oa  Cka  nfaialory  apaeti  of 
iatareoaaardoa  an  o*7end  aad  (ba  papat  coadadat  aids  a  ttataaMBl 
ot  opaa  naaank  paoMamt  aad  toan  taaudn  coadaMoaa. 

I.  iHTkOOUCnON 

IT  IS  THE  THEME  ol  many  papen  w  ihu  iwue.  that  people 
nacd  access  to  data  resources.  In  many  cases  thu  acccM 
must  be  over  large  distances,  in  others  it  may  be  local  to  a 
buUdins  or  a  tingle  site  Data  networks  have  been  nt  up  to 
meet  many  user  needs -often,  but  not  nacetsaniy.  using  packet- 
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switching  technology.  For  single  organizations.  ihcK  data 
networks  art  often  pnvatc  ones,  built  with  a  teciinology 
opiimued  to  the  speciftc  application.  For  communicauon 
between  orpnizations,  these  networks  art  being  set  cp  by 
licensed  carriers.  In  North  Amersca.  there  are  many  such 
bcensed  carrers,  eR.  TELENET  {!).  OaTAPAC  Ui.  and 
TYMNET  PI  In  Uie  rest  of  the  world,  the  Post.  Telegraph, 
and  Telephone  Authority  (PTT)  in  each  country  has  a  near 
monopoly  on  such  services,  special  pubbe  data  networks 
being  set  up  in  these  countries  include  TRANSfAC  |5!  in 
France.  EURONET  U1  for  inicr-European  traffic.  DDX  I  7) 
in  Japan,  EDS  1 81  in  ihe  Federal  Repubbe  of  Germany,  snd 
the  Nordic  Pubbe  Data  Network  (NPDN,  (91)  in  Scandinsna. 
These  pubbe  data  networks  are  considered  in  greater  detail 
in  other  references  (e  g  .  1 10) -|  12) )  Most  of  the  above  net¬ 
works  use  packel-iwitchsng  technology,  some  of  them,  eg. 
EDS  and  the  .S’PDN,  do  r  ot  do  so  yet.  but  may  do  so  in  the 
furore  In  some  cases  spcvial  data  networks  have  been  sutho- 
need  for  specific  communi!  ea.  e  g  .  SIT  A  (131  for  the  aiibncs. 
and  SWIFT  |  Mj  for  the  ba.ska.  In  addition  many  private  net¬ 
works  have  been  set  up  amsng  individual  orgat.uations.  and 
eipenmcntal  networks  of  different  technologies  have  been 
developed  also.  eg.  ARPA.iiET  (IS),  l!6i.  C^. LADES 
ini.  ETHERNET  (IS).  SPYOER  1191.  PRNET  CO),  ('ll 
and  S.\TNETC:i. 
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It  is  a  common  user  requirement  that  a  single  terminal  and 
access  port  should  be  able  to  access  any  computing  resource 
the  user  may  desire-even  if  the  resource  is  on  another  data 
network.  From  this  requirement,  there  is  a  clear  user  need  to 
have  data  networks  connected  together.  By  the  same  token, 
the  providers  of  data  network  services  would  like  to  have  their 
i*et works  used  as  intensively  as  possible;  thus  they  also  have  a 
strong  motivation  to  connect  their  data  networks  to  others. 
As  a  result  of  these  considerations,  there  hu  been  a  high 
recent  interest  in  the  issues  arising  in  the  connection  of  data 
networks  [23)-k26],  [321. 

From  the  user  viewpoint,  the  requirement  for  interconnec¬ 
tion  of  data  networks  is  independent  of  the  network  tech¬ 
nology.  From  the  implementation  viewpoint,  there  can  be 
some  considerable  complications  in  connecting  networks  of 
wid,ily  different  technologies-such  as  circuit-switched  and 
datsgram  packet-switched  networks  (these  terms  are  explained 
belPH').  On  the  whole  we  will  consider  only,  in  this  paper,  the 
interconnection  of  packet-switched  dati  networks.  In  many 
ctns,  however,  the  arguments  will  be  equally  valid  for  the  inter¬ 
connection  of  packet-switched  to  circuit-switched  networks. 

Ketwork  interconnection  raises  a  great  many  technical,  legal, 
and  political  questions  and  issues.  The  technical  issues  gen- 
enJly  revolve  around  mechanisms  for  achieving  interconnec¬ 
tion  and  their  performance.  How  can  networks  be  intercon¬ 
nected  so  th.tt  packets  can  flow  in  a  controllable  way  from  one 
net  to  another?  Should  all  computer  systems  on  all  nets  be 
able  to  communicate  with  each  other?  How  can  this  be 
achieved?  What  kind  of  performance  can  be  achieved  with  a 
set  of  interconnected  networks  of  widely  varying  internal 
design  and  operating  characteristics?  How  are  terminals  to  be 
g:ven  access  to  resources  in  other  networks?  What  protocols 
are  inquired  to  achieve  thi>?  Should  the  protocols  of  one  net 
be  translated  into  those  of  another,  or  should  common  proto¬ 
cols  be  defined?  What  kinds  of  communication  protocol 
standards  are  needed  to  support  efficient  and  useful  inter¬ 
connection?  Who  should  take  responsibility  for  aetting 
standards? 

Tne  legal  and  political  issues  are  at  least  as  complex  as  the 
technical  ones.  Can  private  networks  interconnect  to  each 
other  o;  must  they  do  so  through  the  mediation  of  a  public 
network?  How  is  privacy  to  be  protected?  Should  there  be 
control  over  the  kinds  of  data  which  move  from  one  net  to 
another?  Are  there  international  agreemenu  and  conventions 
which  might  be  affected  by  international  interconnection  of 
data  networks?  What  kinds  of  charging  and  accounting 
policies  should  apply  to  multinetwork  ii  iffic?  How  can  faults 
and  erron  be  diagnosed  in  a  multinst  environment?  Who 
should  be  responsible  for  correcting  such  faults?  Who  should 
be  responsible  for  maintaining  the  gateways  which  connect 
nets  together? 

We  cannot  possibly  a.nswer  all  of  these  questions  in  this 
paper,  but  we  deal  with  many  of  them  iii  ih*  ieCuOn* 

This  paper  is  divided  into  eleven  sections,  in  the  next  sec¬ 
tion  we  provide  some  definitions,  and  In  Section  III  we  ex¬ 
plore  some  of  the  motivations  for  network  interconnection. 
!n  Section  !V  we  discuss  the  range  of  end-user  service  require¬ 
ments  and  choices  for  providing  mulLietwork  service.  Section 
V  reviews  the  concept  of  computer- communication  protocol 
layering.  Section  VI  reviews  the  basic  interconnection  choices 
and  uitroduces  the  concept  of  gateways  between  nets,  proto¬ 
col  translation  end  the  impact  of  co.mmon  protocols;  it  elabo¬ 
rates  also  on  the  function  of  gateways.  Section  VII  discusses 


the  CCITT  recommendations  X.25  and  X.75  and  their  role  in 
network  interconnection.  Section  vni  describes  some  of  the 
network  interconnections  achieved  and  some  of  tlie  experi¬ 
ments  in  progress.  Section  IX  outlines  regulatory  issues  raised 
by  network  interconnection  alternatives.  Section  X  mentions 
some  unresolved  research  questions,  and  the  final  section 
offers  some  tentative  conclusions  on  network  interconnection 
issues. 

II.  The  Dernition  of  Terms 

The  vocabulary  of  networking  is  extensive  and  not  always 
consistent.  We  introduce  some  generic  terms  below  which  we 
will  use  in  this  paper  for  purposes  of  discussion.  It  is  impor¬ 
tant  for  the  reader  not  to  make  any  a  priori  assumptions  about 
the  physical  realization  of  the  objects  named  or  of  the  bound¬ 
ary  of  jurisdictions  owning  or  managing  them.  For  instance, 
a  gateway  (see  below)  might  be  implemented  to  ihare  the 
hardware  of  a  packet  switch  and  be  owned  by  a  packet-switch¬ 
ing  service  carrier;  alternatively  it  might  be  embedded  in  a  host 
computer  which  subscribes  to  service  on  two  or  more  com¬ 
puter  networks.  Roughly  speaking,  we  are  assigning  names  to 
groups  of  functions  which  may  or  may  not  be  realized  as 
physically  distinct  entities. 

Packet:  A  packet  of  information  is  a  finite  sequence  of  bits, 
divided  into  a  control  header  part  and  a  data  part.  The  header 
will  contain  enough  information  for  the  packet  to  be  routed 
to  its  destination  There  will  usually  be  some  checks  on  each 
such  packet,  so  that  any  switch  through  which  the  packet 
passes  may  exercise  error  control.  Packets  are  generally 
associated  with  internal  packet-network  operation  and  are  not 
necessarily  visible  to  host  computers  attached  to  the  network. 

Datagram:  A  finite  length  packet  of  data  together  with 
destination  host  address  information  (and,  usually,  source 
addreu)  which  can  be  exchanged  in  its  entirety  between  hosts, 
independent  of  all  other  datagrams  tent  through  a  packet 
switched  network.  Typically,  the  maximum  length  of  a  data¬ 
gram  lies  between  1  Oclo  and  8000  bits. 

Gateway:  The  collection  of  hardware  and  software  required 
to  effect  the  interconnection  of  two  or  more  data  networks, 
enabling  the  pasuge  of  user  data  from  one  to  another. 

Host:  The  collection  of  hardware  and  software  which  uti¬ 
lizes  the  basic  packet-switching  service  to  support  end-to-end 
interprocess  communication  and  user  services. 

Packet  Switch:  The  collection  of  hardware  and  software  re¬ 
sources  which  implements  al.*  intranetwork  procedures  such  as 
routing,  resource  a’)o:at:on,  and  enur  control  and  provides  ac¬ 
cess  to  network  packet -ewitching  services  through  s  host/ 
network  interface. 

Protocol:  A  set  of  communication  conventions,  including 
formats  and  procedures  which  allow  two  or  more  end  points 
to  communicate.  The  end  points  may  be  packet  twitches, 
hosts,  terminals,  people,  file  system:,  etc. 

tfoiocoi  Tunshlor:  A  collection  of  loftwart,  and  possibly 
hardware,  required  to  convert  the  high  level  protocols  used  in 
one  network  to  those  used  in  another. 

Terminal:  A  collection  of  hardware  and  possibly  software 
which  may  be  as  simple  as  a  character-mode  teletype  or  u 
complex  as  a  full  scale  computer  system.  As  terminals  increase 
in  capability,  the  distinction  between  “host"  and  "terminal" 
may  become  a  matter  of  nomenclature  without  technical 
substance. 

Virtual  Cirevt::  A  lo^cal  channel  between  source  and  desti¬ 
nation  packet  switches  in  a  packet  svkitclred  network.  A 
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virtual  circuit  requires  some  form  of  "setup"  which  may  or 
may  not  be  visible  to  the  subscriber.  Packets  sent  on  a  virtual 
circuit  are  delivered  in  the  order  sent,  but  with  varying  delay. 

PTT:  Technically  PTT  stands  for  Post,  Telegraph,  and  Tele¬ 
phone  Authority;  this  authority  has  a  different  form  in  differ¬ 
ent  countries.  In  this  paper,  by  PTT  we  mean  merely  the 
authority  (or  authorities)  licensed  in  each  country  to  offer 
public  data  transmission  services. 

We  have  attempted  to  make  these  definitions  as  noncontro- 
versial  as  possible.  For  example,  in  the  definition  of  packet 
switch,  we  alluded  to  a  host/network  interface.  Tne  reader 
should  not  assume  that  subscriber  services  are  limited  to  those 
offered  through  the  host/network  interface.  The  packet¬ 
switching  carrier  might  also  offer  host-based  services  and 
terminal  access  mechanisms  as  additional  subscriber  serdces. 

ni.  The  Motivating  Forces  in  the 
Interconnection  of  Data  Networks 

In  the  introduction,  we  mentioned  that  there  was  a  strong 
interest,  among  both  the  users  and  supplien  of  data  serivces,  in 
the  interconnection  of  data  networks.  However,  the  technical 
interests  of  the  different  parties  are  not  identical.  The  end 
user  would  merely  like  to  be  able  to  access  any  resources  from 
a  single  terminal,  with  a  single  access  port,  as  economically 
as  possible  according  to  his  own  performance  criteria.  A 
Public  Carrier,  or  PTT,  has  a  strong  motivation  to  connect  its 
network  to  other  PTT’s.  As  in  the  telephone  system,  the 
concept  of  all  subscribers  being  accessible  through  a  siiigle 
Public  Data  Service,  is  considered  highly  desirable;  however 
the  different  PTT's  may  have  restricted  geographic  coverage, 
or  only  a  specific  market  penetration. 

The  motivation  of  the  PTT's  to  interface  to  private  networks 
is  weaker  and  more  complex.  They  always  provide  facilities 
to  attach  single  terminals,  where  a  terminal  may  be  a  complex 
computer  system;  they  are  often  not  interested,  at  present,  in 
making  any  special  anangements  when  the  "terminal"  is  a 
whole  computer  network.  The  operators  of  private  networks 
often  have  a  vital  interest  in  connecting  their  networks  to 
other  private  networks  and  to  the  public  ones.  Even  though 
in  many  cases  the  bulk  of  its  traffic  is  internal  to  the  private 
network,  which  is  why  it  was  set  up  in  the  fust  place,  there  is 
usually  a  vital  need  to  access  resources  .net  available  on  that 
network.  The  regulatory  limitations  often  imposed  on  the 
method  of  interconnection  of  private  networks  are  discussed 
in  Section  IX.  in  some  countries,  it  is  not  permitted  to  build 
private  networks  using  leased  line  services,  but  intrabuilding 
networks  may  be  permitted.  Interrcnnection  of  such  local 
networks  to  public  networks  may  play  a  crucial  role  in  making 
the  local  network  useful. 

To  date  the  PTT’s  have  tried  to  standardize  on  access  pro¬ 
cedures  for  their  Public-Packet  Data  Services.  The  standardiza¬ 
tion  has  taken  place  in  the  International  Consultative  Commit¬ 
tee  on  Teie^phy  and  Telephony  (called  CCITT}  in  a  set  of 
recommendations  caUed  X.3,  X.2.5,  X.28,  ard  X.29  ([21]- 
129) ).  Net  all  PTT’s  have  such  forms  of  access  yet,  but  most 
of  the  industrialized  nations  in  the  West  ait  moving  in  this 
direction.  Tlw  series  of  recommendations  is  discussed  in 
much  more  detail  in  Section  VI;  it  does  not  pay  special  atten- 
'aon  to  the  attachment  of  private  networks  ((31),  [32)),  but 
tlie  recommendations  are  themselves  expected  to  change  to 
meet  this  requirement.  The  PTT’s  are  agreeing  on  a  set  of  inter¬ 
face  recommendations  and  procedures  called  X.7S  (33),  to 
connect  their  networits  to  each  other;  so  far  this  interface 
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procedure  (and  its  corresponding  hardware)  is  not  intended 
to  be  provided  to  private  networks. 

While  most  PTT’s  have  preferred  to  ignore  the  technical 
implications  of  the  attachment  of  private  networks  to  the 
public  ones,  most  private  network  operators  cannot  ignore 
this  requirement.  They  are  often  motivated  to  add  some  extra 
’’Foreign  Exchange"  capability  as  an  afterthought,  with  mini¬ 
mum  change  to  their  intranetwork  procedures;  this  approach 
can  be  successful  up  to  a  point,  but  will  usually  be  limited  by 
the  lack  of  high-level  procedures  between  the  different  net¬ 
works.  These  high-level  procedures  have  not  yet  been  con¬ 
sidered  by  CCITT,  but  iit  has  been  proposed  that  CCITT  Study 
Group  VII  investigate  liigh-level  procedures  and  architectural 
models,  in  cooperation  with  the  investigation  of  "open  system 
architectures’’  by  Technical  Committee  97.  Sub-Committee 
16  of  the  International  Standards  Organisation  (ISO).  This 
subject  is  also  considered  later  in  this  paper,  in  Section  VI. 

An  aim  of  these  standardization  exercises  is  to  ensure  that 
both  manufacturer  and  user  implementations  of  network 
resources  can  communicite  with  each  other  through  single 
private  or  public  data  networks.  A  consequence  should  be 
that  the  resources  are  also  compatibly  accessible  over  con¬ 
nected  data  networks. 

Depending  on  the  applications  and  spatial  distribution  of 
subscribers,  the  preferred  choice  of  packet-switching  medium 
will  vary.  Intrabuilding  appiiicatioris  such  as  electronic  office 
services  may  be  most  economically  provided  through  the  use 
of  a  coaxial-packet  cable  systen\  such  as  the  Xerox  ETHERNET 
(18)  and  LCSNET  [64],  or  twisted  pair  rings  such  as  DCS 
[34],  coupled  with  a  mix  of  self-contained  user  computers 
(e.g.,  intelligent  terminals  with  substantial  computing  and 
memory  capacity)  and  shared  computing,  storage,  and  input- 
output  facilities.  Larger  area  regional  applications  might  best 
employ  shared  video  cables  [35]  or  packet  radios  [20] ,  (21] 
for  mobile  use.  National  systems  might  be  composed  of  a  mix¬ 
ture  of  domestic  satellite  channels  and  conventional  leased- 
line  services.  International  systems  might  use  point-to-point 
links  plus  a  shared  communication  satellite  channel  and  multi¬ 
ple  ground  stations  to  achieve  the  most  cost-effective  service. 

A  consequence  of  the  wide  range  of  technologies  which  are 
optimum  for  different  packet-switching  applications  is  that 
many  different  networks,  both  private  and  public,  may  co-exist. 
A  network  interconnection  strategy,  if  properly  designed,  will 
permit  local  networks  to  be  optimized  without  sacrificing  the 
possibility  of  providing  effective  internetwork  services.  The 
potential  v^onomic  and  functional  advantages  of  local  net¬ 
works  such  as  ETHERNET  or  DCS  will  lead  naturally  to  pri¬ 
vate  user  networks.  Such  private  network  developments  are 
analogous  to  tele /hone  network  private  automated  branch 
exchanges  (PABX)  snd  represent  a  natural  consequence  of 
the  marriage  of  computer  and  telecommunication  technology. 

Two  further  developments  can  be  expected.  Fint,  organiza¬ 
tions  which  are  dispersed  geographically,  nationally,  or  inter¬ 
nationally,  will  want  to  interconnect  these  private  networks 
both  to  share  centralized  resources  and  to  effect  Lntraerganiza- 
tion  electronic  mail  and  other  automated  office  services. 
Second,  there  wUl  be  an  increasing  interest  in  interorganization 
interconnections  to  allow  automated  procurement  and  financial 
transaction  services,  for  example,  to  be  applied  to  interorgani¬ 
zation  affairs. 

In  most  countries  where  private  networks  are  permitted, 
interorganization  telecommunication  requires  the  involvement 
of  a  PTT.  Hence  the  most  typical  network  interconnection 
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scenarios  wiU  involve  three  or  four  networks.  Within  one  na¬ 
tional  administration  the  private  nets  of  different  organiza¬ 
tions  will  be  interconnected  through  a  public  network.  Inter¬ 
national  interconnections  will  involve  at  least  two  public 
networks.  We  will  return  to  this  topic  in  Section  VI. 

In  addition  to  permitting  locally  optimized  networks  to  be 
interconnected,  a  network  mterconnection  strategy  should 
also  support  the  gradual  introduction  of  new  networking 
technology  into  existing  systems  without  requiring  simul¬ 
taneous  global  change  throughout.  This  consideration  leads 
to  the  conclusion  that  the  public  data  networks  should  sup¬ 
port  the  most  important  user  requirements  for  internet  service 
from  the  outset.  If  this  were  the  case,  then  changes  in  net¬ 
work  technology  which  require  a  multinetwork  system  during 
phased  transition  would  not,  a  priori,  have  to  affect  user 
services. 

IV.  Provision  of  End-User  Multinetwork  Services 

The  ultimate  choice  of  a  network  interconnection  strategy 
will  be  strongly  affected  by  the  types  of  user  services  which 
must  be  supported.  It  is  useful  to  consider  the  range  of  exist¬ 
ing  and  foreseeable  user  service  requirements  without  regard 
for  the  precise  means  by  which  these  requirements  are  to  be 
met.  We  will  leave  for  discussion  in  subsequent  sections  the 
choice  of  supporting  the  various  services  within  or  external  to 
the  packet-switched  network.  The  types  of  service  discussed 
below  are  general  requirements  for  network  facilities.  For  this 
reason  they  auso  should  be  supported  across  interconnected 
networks. 

Most  of  the  currently  prevalent  computer- communication 
services  fall  into  four  categories: 

1)  terminal  access  to  time-shared  host  computers, 

2)  remote  job  entry  services  (RJE); 

3)  bulk  dsta  trarufer; 

4)  transaction  processing. 

The  timeHharing  and  transaction  services  typically  demand 
short  network  and  host  response  times  but  modest  bandwidth. 
The  Ri£  and  file  transfer  services  mott  often  require  high 
amounts  of  data  transfer,  but  can  tolerate  longer  delay.  Some 
networks  were  designed  to  support  primarily  terminal  service, 
leaving  RJE  or  ule  transfer  services  to  be  supported  by  dedi¬ 
cated  leased  lines.  Packet-switching  techniques  permit  both 
types  of  service  to  be  supported  with  common  network 
resources,  leading  to  verifiable  economies.  However,  bulk 
data  transfer  requires  increasingly  higher  throughput  rates  if 
delivery  delays  are  to  be  kept  constant  as  the  amou.nt  of 
data  to  be  transferred  increases. 

As  distributed  opefating  rysieiTii  become  more  prevalent, 
there  will  be  an  increased  need  for  host-to-host  tranuction 
services.  A  prototypical  example  of  such  a  system  is  found  in 
the  DARPA  National  Software  Works  (4),  (36).  In  such  a 
system,  small  quantities  of  control  information  must  be  ex¬ 
changed  quickly  to  coordinate  the  activity  of  the  distributed 
components.  Broadcast  or  multidestination  services  will  be 
needed  to  support  distributed  file  systems  in  which  informa¬ 
tion  can  be  stored  redundantly  to  improve  the  reliability  of 
acceu  and  to  protect  against  catastrophic  failures. 

Transaction  services  are  also  rinding  application  in  reserva¬ 
tion  systems,  credit  verification,  point  of  sale,  and  electronic 
funds-transfer  systems  in  which  hundreds  or  thousands  of 
terminal*  supply  to,  or  request  of,  hosts  small  amounts  of 
information  at  random  intervals.  Real-time  data  vcllcctinn  fot 


weather  analysis,  ground  and  air  traffic  control,  and  meter 
reading,  for  example,  also  fall  into  this  category. 

More  elaborate  user  requirements  can  be  foreseen  as  elec¬ 
tronic  mail  facilities  propagate.  Multiple  destination  address¬ 
ing  and  end-to-end  encryption  for  the  protection  of  privacy 
as  well  as  support  for  text,  digitized  voice,  and  facsimile  mes¬ 
sage  transmission  are  all  likely  requirements.  Electronic  tele¬ 
conferencing  using  mixtures  of  compressed  digital  packet 
speech,  videographics,  real-time  cursors  (for  pointing  at  video 
images  under  discussion),  and  text  display  will  give  rise  to  re¬ 
quirements  for  closed  user  groups  and  time-synchronized 
mixes  of  transaction-like  (e.g.,  for  cursor  tracking  and  packet 
speech)  and  reliable  drcuit-like  services  (e4.,  for  display 
management). 

Reliability  and  rapid  response  will  be  increasingly  important 
as  more  and  more  computer-based  applications  requiring  tele¬ 
communications  are  integrated  into  the  business,  government, 
military,  and  social  fabric  of  the  world  economy.  The  more 
such  systems  are  incorporated  into  their  daOy  activities,  the 
more  vulnerable  the  subscribers  are  to  failures.  Reliability 
concerns  lead  to  the  requirement  for  redundant  alternatives 
such  as  distributed  file  systems,  richly  connected  networks, 
and  substantial  local  processing  and  storage  capability.  These 
trends  increase  the  need  for  networking  to  share  common 
hardware  and  software  resources  (and  thus  reduce  their  mar¬ 
ginal  cost),  tc  lupport  remote  software  maintenance  and  de¬ 
bugging.  and  to  suppon  intra-  and  inter-organizational  info^ 
mation  exchange. 

We  have  described  the  end-user  services  required  across  one 
or  more  data  networks.  We  have  carefully  refrained  from  dis¬ 
cussing  which  servicos  should  be  provided  in  the  data  network, 
and  which  should  be  provided  in  the  hosts.  Here  the  choice 
in  single  networks  will  depend  on  the  network  technologr  fad 
the  application  requirements.  For  example,  in  a  network  using 
a  broadcast  technology  such  as  ETHERNET  or  the  SATNFT, 
multidestination  facilities  may  well  be  incorporated  in  the  dsta 
network  itself.  In  typical  itore-and-forward  networks,  this 
feature  mi^t  be  provided  at  the  host  level  by  the  tTaiun:^*on 
of  multiple  copies  of  packets.  This  example  highlights  im¬ 
mediately  the  difficulty  of  using  sophisticated  services  at  the 
data  network  level  across  concatenated  networks.  If  A,  B, 
and  C  are  data  networks  connected  as  in  Fig.  1 ,  and  A  and  C 
but  not  B  support  broadcast  or  real-time  features,  it  is  very 
cifricult  to  provide  them  across  the  concatenation  of  4,  R, and 
C. 

The  problem  of  achieving  a  useful  set  of  internetwork  aer- 
vicss  might  be  approa.chcd  in  several  ways,  as  follows. 

1)  Require  all  networks  to  implement  the  entire  range  of 
desired  senri^  (e.g.,  datagram,  virtual  cuouit,  broadcast,  real- 
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time,  etc.),  and  then  attempt  to  support  these  services  across 
the  gateways  between  the  networks. 

2)  Require  all  networks  to  implement  only  the  most  basic 
services  (e.g.,  datagram  or  virtual  circuit),  support  these  ser¬ 
vices  across  gateways,  and  rely  on  the  subscriber  to  imple¬ 
ment  all  other  services  end-to-end. 

3)  Allow  the  subscriber  to  identify  the  services  which  he 
desires  and  provide  error  indications  if  the  networks  involved, 
or  the  gateways  between  them,  cannot  provide  the  desired 
services. 

4)  Allow  the  subscriber  to  specify  the  internetwork  route  to 
be  followed  and  depend  on  the  subscriber  to  decide  which 
concatenation  of  services  are  appropriate  and  what  end-to-end 
protocols  are  needed  to  achieve  the  ultimately  preferred  class 
of  service. 

5)  Provide  one  set  of  services  for  local  use  within  each  net¬ 
work  and  another,  possibly  different  set  for  internetwork 
use. 

The  Hve  choices  above  are  by  no  means  exhaustive,  and,  in 
fact,  only  scratch  the  surface  of  possibilities.  Nothing  has 
been  said,  thus  far,  about  the  compatibility  of  various  levels 
of  communication  protocols  which  exist  within  each  network, 
within  subscriber  equipments,  and  within  the  logical  gateway 
between  networks.  To  explore  these  issues  further,  it  will  be 
helpful  to  have  a  model  of  internetwork  architecture,  taking 
into  account  the  common  principle  of  protocol  layering  and 
the  various  possible  choices  of  interconnection  strategy  which 
depend  upon  the  protocol  layer  at  which  the  networks  are 
interfaced.  We  consider  this;  in  the  next  section. 

V.  Layered  Protocol  Concei'TS 

Both  to  provide  services  in  single  networks,  and  to  compare 
the  capabilities  of  different  networks,  a  very  useful  concept 
in  networking  is  protocol  layering.  Various  services  oi  increas- 
mg  capability  can  be  built  one  on  top  of  the  other,  each  using 
the  facilities  of  the  service  layer  below  and  supporting  the 
facilities  of  the  layer  above.  A  thorough  tutorial  on  this  con¬ 
cept  can  be  found  in  the  paper  by  Pouzin  and  Zimmermann  in 
this  issue  (37) .  We  give  some  specific  examples  below  of  layer¬ 
ing  as  a  means  of  illustrating  the  scope  of  services  and  inter¬ 
faces  to  be  found  in  packet  networks  today -and  some  of  the 
problems  er^countered  in  offering  services  across  multiple 
networks. 

Table  I  offen  a  very  generic  view  of  a  typical  protoco' 
hierarchy  in  a  store- and-forward  computer  network,  including 
layen  usually  found  outside  of  the  communication  network 
itself.  There  art  several  complications  to  the  use  of  generic 
protocol  layering  to  study  network  interconnection  issues. 
Chief  among  these  is  that  networks  do  not  all  co;.uin  the  same 
elements  of  the  generic  hierarchy.  A  second  complication  is 
that  some  networks  implement  service  functions  at  different 
protocol  layers.  For  instance,  virtual  circuit  networks  imple¬ 
ment  an  end/end  subsenber  virtual  cucuit  in  their  intranet, 
end/end  level  protocol.  Fuially.  the  hierarchical  ordering  of 
functions  is  not  always  the  ume  in  all  networks.  For  instance. 
TYMNET  places  a  terminal  handling  protocol  within  the  net¬ 
work  access  layer,  so  that  hosts  look  to  each  other  like  one  or 
more  terminals.  Figs.  2>7  illustrate  the  functional  layering 
of  sorre  different  networks.  !t  is  unporiant  to  note  how  the 
functions  vary  with  the  choice  of  transmission  medium 

A.  ETHERNET 

In  Fig.  2.  we  reprerent  the  Xerox  ETHERNET  protocol 
hierarchy.  The  basic  bnk  control  mechanism  is  the  ability  of 
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TABLE  I 

Generic  Protucol  Layers 


woTocoi  lArtn 

FUNCTIONS 

S.  AmiCATION 

FUNDS  TRANSFER.  INFORMATION 
RETRIEVAL  EUCTRONIC  MAIL 

TEXT  EOmNO  . .  . 

s.  unuTV 

FILE  TRANSFER.  VIRTUAL  TERMINAL 
SUFRORT 

4.  ENO<ENO  SUBSCRIKR 

INTERFftOCESS  COMMUNICATION 
(E  G  VIRTUAL  CIRCUIT.  DATAGRAM. 
REALTIME.  BROADCAST) 

3.  NETWORK  ACCESS 

NETWORK  ACCESS  SERVICES 

iZ.G.  VIRTUAL  CIRCUIT.  DATAGRAM  . . .) 

Z  INTRANET.  ENO-TOENO 

FLOW  CONTROL  SEQUENONG 

1.  INTRANET.  NODE  TO^NOOC 

CONGESTION  CONTROL  ROUTING 

e  UNK  CONTROL 

ERROR  HANOUNO.  UNK  FLOW  CONTROL 

AFFUCATION 

— 

unuTV 

FILE  TRANSFER  VIRTUAL  TERMINAL 

DIRECTORY  LOOK  UF. 

file  accss 

ENOTOFNO 

SUBSCRIBER 

STREAM  FROTOCOL 

RELIABLE  RACKET  FROTOCOL 

NETWORK  ACCEM 

BROADCAST  DATAGRAM  lUNRfUASU) 

UNK  CONTROL 

Fig.  3.  ETHERNET  protocol  layering. 


the  interface  device  to  detect  conflict  on  a  shared  coaxial  cable. 
If  a  transmitting  interface  detects  that  another  interface  is 
also  transmitting,  it  immediately  aborts  the  transmission. 
Hosts  attached  to  the  network  interface  present  datagrams  to 
be  transmitted  and  are  told  if  the  datagram  was  aborted. 
Datagrams  can  be  addressed  to  specific  interfaces  or  to  all  of 
them.  The  end/end  subscriber  layer  of  protocol  is  split  into 
two  parts:  a  reliable  datagram  protocol  in  which  each  data- 
gra.m  is  reliably  delivered  and  separately  acknowledged,  and 
a  stream  protocol  which  can  be  thought  of  as  a  virtual  circuit. 
This  spLt  is  possible,  in  part,  because  there  is  a  fairly  large 
maxirium  datagram  size  (shout  500  bytes)  so  that  user  appli¬ 
cations  can  send  datagrams  without  having  to  fragment  and 
reassemble  them.  This  makes  the  datagram  service  useful  for 
many  applications  which  might  otherwise  have  to  use  the 
stream  protocol.  All  higher  level  protocols,  such  as  Virtual 
Terminal  and  File  Transfer,  are  earned  out  in  the  h<»ts. 

B.  ARPANET 

The  ARPANET  protocol  hierarchy  is  shown  in  Fig.  3.  The 
baric  link  ccnirol  between  packet  switches  treats  the  physical 
link  as  eight  independent  virtual  links.  Thir  increases  effec¬ 
tive  throughput,  but  docs  not  necessarily  preserve  the  order 
in  which  packets  were  originally  introduced  into  the  network 
The  intranet  node-io-nodc  protocols  deal  with  adaptive  rout¬ 
ing  decisions,  store- and-forward  service  and  congestion  con¬ 
trol.  Hosts  have  the  option  of  either  passing  messages  (up  to 
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8063  bits  of  text)  across  the  host/network  interface,  which 
will  be  delivered  in  sequence  to  the  destination,  or  passing 
datagrams  (up  to  1 008  bits  of  text)  which  arc  not  necessarily 
delivered  in  sequence.  The  user’s  network  access  interface  is 
datagram-like  in  the  sense  that  no  circuit  setup  exchange  is 
needed  even  to  activate  the  sequenced  message  service.  In 
effect,  this  service  acts  like  a  permanent  virtual  circuit  over 
which  a  sequence  of  discrete  messages  are  sent.  For  the 
sequenced  messages,  there  is  exactly  one  virtual  circuit  main¬ 
tained  for  each  host/host  pair.  In  fact,  these  virtual  circuits 
are  set  up  dynamically  and  terminated  by  the  source/destina¬ 
tion  packet  switches  so  as  to  improve  resource  utilization 
138). (621. 

The  end/end  subscriber  layer  of  ARPANET  containr  two 
main  protocols:  Network  Control  Protocol  (NCP,  (39),  (40)) 
and  Transmission  Control  Protocol  (TCP,  (25) ).  NCP  was  the 
first  interprocess  communication  protocol  built  for  ARPANET. 
It  relies  on  the  sequenced  message  service  provided  by  the  net¬ 
work  and  derives  multiple  virtual  circuits  between  pairs  of 
hcs  s  by  multiplexing.  The  TCP  ran  use  either  the  sequenced 
mes:;age  service  or  the  datagram  service.  It  does  its  own 
sequencing  and  end/end  enor  control  and  derives  multiple 
virtual  circuits  through  extended  ad^essing  and  multiplexing. 
TCP  was  designed  for  operation  in  a  multinet  environment  in 
which  the  only  service  which  reasonably  could  be  expected 
was  an  unrehable,  unsequenced  datagram  service. 

To  support  experiments  in  packetized  voice  communication, 
two  protocols  were  developed  for  use  on  the  ARPANET.  The 
Network  Voice  P.otocol  (NVP)  snd  Network  Voice  Confer¬ 
encing  Protocol  (NVCP)  use  the  datagram  service  to  achieve 
very  low  delay  and  interarrival  time  variance  in  support  of 
digital,  compressed  packet  speech  (more  on  these  protocols 
may  be  found  in  (41)).  The  NVP  could  be  considered  the 
basis  for  a  generic  protocol  wlach  could  support  a  variety  of 
real-time,  end/end  user  applications. 

The  higher  level  utihty  protocols  such  u  terminal/host 
protocol  (TELNET,  (40).  (4?j)  and  file  transfer  protocol 
(FTP.  (40) .  (42) ) use  virtual  circuits  provided  by  NCP  or  TCP. 
The  FTP  requires  one  live  interactive  stream  to  control  the 
data  transfer,  and  a  second  for  the  data  stream  itself.  Yet 
higher  level  applications  such  as  electronic  mail  and  remote 
job  entry  (RJE,  (40),  (42))  use  mixtures  of  TELNET  and 
FTP  to  effect  the  service  desired.  These  protocols  are  usually 
put  into  the  hosts  There  is  one  anomaly,  which  occurs  in 
many  networks.  Because  terminal  handhng  is  required  so 
frequently,  a  Terminal  Interface  Message  Prcxessor  (TIP.  (43) ) 
was  built.  This  device  is  physically  integrated  with  the  packet 
switch  (IMP,  (38)).  it  includes  also  the  NCP  and  TELNET 
protocols. 
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C.  TYMNET 

TYMNET  (sec  Fig.  4)  is  one  cf  the  oldest  of  the  networks  in 
the  collection  described  here  (3).  Strictly  speaking,  it  oper¬ 
ates  rather  differently  than  other  packet-switched  networks, 
because  the  frames  of  data  that  move  from  switch  to  switch 
are  disassembled  and  reassembled  in  each  switch  as  an  integral 
part  of  the  store- and-forward  operation.  Nevertheless,  the  net¬ 
work  benefits  from  the  asynchronous  sharing  of  the  circuits 
oetween  the  switches  in  much  the  same  way  that  more  typical 
packet-switched  networks  do.  The  network  was  designed  to 
support  remote  terminal  access  to  time-shared  computer  re¬ 
sources.  The  basic  service  is  the  transmission  of  a  stream  of 
characters  between  the  terminal  and  the  serving  host.  A 
frame  is  made  up  of  one  or  more  blocks  of  characters,  each 
block  labeled  with  its  source  terminal  identifier  and  length. 
The  switch-to-switch  layer  of  protocol  disassembles  each  frame 
into  its  constituent  blocks  and  uses  a  routing  *able  to  deter¬ 
mine  to  which  next  switch  the  block  should  be  sent.  Blocks 
destined  for  the  same  next  switch  are  batched  together  in  a 
frame  which  is  chtckrummed  and  sent  via  the  link  control 
procedure  to  the  next  switch.  Batching  the  blocks  reduces 
line  overhead  (the  blocks  share  the  frame  checksum)  at  the 
expense  of  more  CPU  cycles  in  the  switch  for  frame  dis¬ 
assembly  and  reassembly. 

The  protocol  between  TYMNET  switches  also  includes  a 
flow  control  mechanism  which,  because  of  the  flxed  routes, 
can  be  used  to  apply  back  pressure  all  the  way  back  to  the 
traffic  source.  This  is  not  precisely  an  end-to-end  flow  control 
mechanism,  but  a  hop-by-hop  back  pressure  strategy.  Charac¬ 
ter  blocks  are  kept  in  sequence  along  the  flxed  routes  so  that 
no  lesequencing  is  required  as  they  exit  from  the  network  at 
their  destinations.  The  network  interface  is  basically  a  virtual 
circuit  designed  to  transport  character  streams  between  a 
host  and  a  terminal.  The  ume  virtual  circuits  can  be  used  to 
transport  character  streams  between  hosts,  which  look  to  each 
other  like  a  collection  of  terminals.  Above  the  basic  virtual 
circuit  service,  is  a  special  echo-handling  protocol  which 
allows  the  host  and  the  terminal  handler  in  the  “remote 
TYMSAT’  to  coordinate  the  echoing  of  the  characters  typed 
by  a  user. 

D.  PTT  Networks 

Many  PTT  networks,  e  g..  TELNET.  TRANSPAC,  DATA- 
PAC,  and  EURONET  use  a  particular  network-access  protocol, 
X.25  (28),  (29)  (see  Fig.  5).  This  protocol  has  been  recom¬ 
mended  by  the  CX^ITT  for  public  packet-switched  data  .net¬ 
works.  X.25  is  a  three-part  protocol  consuting  of  a  hardware 
electrical  interface,  X.21  (44),  the  digital  equivalent  of  the 
usual  V.24  or  E1A-RS232C  modem  interface  (45).  a  link 
control  procedure,  High  Level  Data  Link  Control  (HDLC, 
(46)),  and  a  packet-level  protocol  for  effecting  the  setup, 
use,  termination,  flow,  and  error  control  of  vinual  ciremu. 
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In  all  but  the  DATAPAC  network,  a  fixed  route  for  routing 
packets  through  the  network  is  selected  at  the  time  the  virtual 
circuit  is  created.  “Permanent"  virtual  circuits  are  a  customer 
option ;  if  used,  the  setup  phase  is  invoked  only  in  the  case  of 
a  network  failure.  Between  source  and  destination  packet 
switches,  a  virtual  circuit  protocol  is  operated  which  imple¬ 
ments  end-to-end  flow  control  on  multiple  virtual  circuits 
between  pairs  of  packet  switches.  Up  to  4096  virtual  circuits 
between  pairs  of  host  ports  can  be  maintained  by  each  packet 
switch,  as  compared  to  the  single  virtual  circuit  provided  by 
ARPANET  (on  which  hosts  can  multiplex  their  own  virtual 
circuits).  This  choice  has  a  noticeable  impact  on  the  sub¬ 
scriber  interface  protocol  which  becomes  complicated  be¬ 
cause  the  subscriber  host  and  the  packet  switch  to  which  it 
attaches  must  maintain  a  consktent  view  of  the  state  of  each 
virtual  circuit  in  use. 

To  provide  for  echo  control,  user  commands,  code  conver¬ 
sion,  and  other  terminal-related  sei-vices,  these  networks 
implement  CCITT  Recommendations  X.28  (29]  and  X.29 
(29]  in  a  PAD  (Packet  Assembly  and  Disassembly  unit). 
These  protocols  sit  atop  the  virtual  circuit  X.25  protocol.  In 
order  to  serve  customers  desiring  a  terminal-to-host  service 
with  character  terminals,  such  as  is  provided  by  TYMNET  or 
by  the  ARPANET  (through  the  TiiP),  most  of  the  PTT  net¬ 
works  mentioned  are  developing  a  PAD  unit.  A  matching 
X.29  (PAD  control  protocol)  layer  must  be  provided  in  hosts 
offering  to  service  terminals  connected  to  PAD's. 

E.  High  Level  Protocols 

The  X.2S/X.28/X.29  protocol  hierarchy  does  not  include  an 
end/end  lubscnber  or  high-level  protocol  layer.  Some  cui- 
tomen  will,  in  fact,  implement  end-to-end  protocols  on  top 
of  the  virtual  circuit  protocol,  but  others  .may  not.  Several 
attempts  are  being  made  to  standardize  protocols  above  the 
network  access  level.  The  ARPANET  community  has  de¬ 
veloped  a  Transmission  Control  Protocol  (25)  for  internet¬ 
work  operation  to  replace  the  Network  Control  Program 
(NCP)  developed  early  in  the  ARPANET  project.  The  Inter¬ 
national  Federation  of  Information  Processing  (IFIP)  has 
proposed  a  Transport  Station  through  its  Worki.n*  Group  6.1 
on  Network  Interconnection  |47) ,  the  proposiJ  has  been  sub¬ 
mitted  to  the  International  Standards  Organisaticn  (ISO)  as 
a  draft  standard.  In  addition,  other  communities,  e  g.,  the 
High  Level  Protocol  Working  Group  in  the  UK,  have  devised 
protocols  for  Virtual  Packet  Terminals  (VPT,  (48))  and  File 
Transport  Protocol  (FTP,  (49) )  which  are  intended  to  be  net¬ 
work  independent  and  which  may  be  submitted  to  CCITT. 
The  ISO  study  on  “open  systems  architecture”  and  the  pro¬ 
posed  similar  study  by  CCITT  Study  Group  VII  will  attempt 
to  evolve  higher  level  protocol  recommendations  for  existing 
and  future  data  networks. 
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This  brief  summary  of  different  network-protocol  layerings 
is  in  no  way  comprehensive,  but  illustrates  the  diversity  of 
protocol  designs  which  can  be  found  on  nets  providing  differ¬ 
ent  types  of  services  to  subscribers. 

VI.  Technical  Interconnection  Choices 

A.  The  Issues 

Beginning  with  the  earliest  papers  dealing  with  strategies 
for  packet-network  interconnection  (23)-(26),  (32),  the 
common  objective  of  all  the  proposed  methods  is  to  provide 
the  physical  means  to  access  the  services  of  a  host  on  one  net¬ 
work  to  all  subscribers  (including  hosts)  of  all  the  intercon¬ 
nected  networks.  Of  course,  limitations  to  this  accessibility 
are  envisaged,  imposed  either  for  administrative  reasons  or 
by  the  scarcity  of  resources.  The  achievement  of  this  objec¬ 
tive  invariably  requires  that  data  produced  at  a  source  in  one 
net  be  delivered  and  correctly  interpreted  at  the  destination(s) 
in  another  network.  In  an  abstract  sense,  this  boils  down  to 
providing  interprocess  communication  across  network  bound¬ 
aries.  Even  if  a  person  is  the  ultimate  source  of  the  data, 
packet-switching  networks  must  interpose  some  degree  of  soft¬ 
ware  processing  between  the  penon  and  the  destination  ser¬ 
vice,  even  if  only  to  assemble  or  disassemble  packets  produced 
by  a  computer  terminal. 

A  fundamental  aspect  of  interprocess  communication  is 
that  no  communication  can  take  place  without  some  agreed 
conven  tions.  The  communicating  processes  must  share  some 
physical  transmission  medium  (wire,  shared  memory,  radio 
spectaim,  etc.),  and  they  must  use  common  conventions  or 
agreed  upon  translation  methods  Li  order  to  successfully  ex¬ 
change  and  interpret  the  data  they  wish  to  communicate.  One 
of  the  key  elements  in  any  network  interconnection  strategy 
is  therefore  how  the  required  commonality  is  to  be  obtained. 
In  some  cases,  it  is  enough  to  translate  one  protocol  into 
another.  In  others,  protocols  can  be  held  in  common  among 
the  communicating  parties. 

In  any  real  network  interconnection,  of  course,  a  number  of 
secondary  objectives  will  affect  the  choice  of  interconnection 
strategy.  For  example  achievable  bandwidth,  reliability, 
robustness  (i.e..  resistance  to  failures),  security,  flexibility, 
accountability,  access  control,  resource  allocation  options,  and 
the  like  can  separately  and  jointly  influence  the  choice  of 
interconnection  strategy.  Combinations  of  strategies  employ¬ 
ing  protocol  standards  and  protocol  translations  at  various 
levels  of  t.be  layered  protocol  hierarchy  are  also  likely 
possibilities. 

There  are  a  number  of  issues  which  must  be  resolved  before 
a  coherent  network  interconnection  strategy  can  be  defined. 
A  list  of  some  of  the:?  issues,  which  will  be  treated  in  more 
detail  in  succeeding  sections,  is: 

1)  level  of  interconnection; 

2)  naming,  addressing,  and  routing; 

3)  flow  and  congestion  control; 

4)  accounting; 

5)  access  control; 

6)  internet  services. 

B.  Gateways  and  Levels  of  Network  Interconnection 

The  concept  of  a  gateway  is  common  to  all  network  mter- 
connection  strategies.  The  fundamental  role  of  the  gateway  is 
to  terminate  the  internal  protocols  of  each  network  to  which 
it  is  attached  while,  at  the  same  time,  providing  a  common 
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ground  across  which  data  from  one  network  can  pass  into 
another.  However,  the  choice  of  functions  to  be  performed  in 
the  gateway  varies  considerably  among  different  interconnec¬ 
tion  strategies  (see  Fig.  6).  The  term  “pteway"  need  not 
imply  a  monoUthic  device  which  joins  a  pair  of  networks.  In¬ 
deed.  the  gateway  may  merely  be  software  in  a  pair  of  packet 
switches  in  different  networks,  or  it  may  be  made  up  of  two 
parts,  one  in  each  network  (a  sort  of  “pteway  half").  In  the 
latter  case,  the  two  halves  might  be  devices  separate  and 
distinct  from  the  network  packet  switches  or  might  be  inte- 
pated  with  them.  Furthermore,  a  gateviray  might  interconnect 
more  than  two  networks.  In  the  materia!  which  foliows. 
every  attempt  has  been  made  to  avoid  any  implicit  choice  of 
pteway  implementation.  It  is  worth  pointing  out.  however, 
that  the  "half  pteway"  concept  u  highly  attractive  from  both 
a  technical  and  a  purely  administrative  point  of  view.  Tech- 
nicaU),  each  half  could  terminate  certain  levels  of  protocol 
of  the  net  to  which  it  is  attached.  Administratively  each  half 
could  be  the  responsibility  of  the  network  to  which  it  belonp 
Then  the  only  matters  for  jurudictional  negotiation  are  the 
physical  medium  by  which  the  half-gateways  exchanp  data, 
and  the  format  and  protocol  of  the  exchanp. 


It  is  important  to  realize  that  typical  applications  may  in¬ 
volve  three  or  more  networks.  Where  local  networks  are  used, 
they  will  usually  need  to  be  interconnected  to  realize  the 
benefits  of  interorpnizational  data  exchange.  In  most  coun¬ 
tries,  such  interconnections  will  only  be  permitted  through  a 
public  network.  Thus  for  a  typical  national  situation,  three 
networks  and  two  gateways  will  be  involved  in  providing  the 
desired  host-to-host  communication. 

The  international  picture  is  similar,  except  that  more  net¬ 
works  are  likely  to  be  involved.  Shown  in  Fig.  7,  the  path 
from  a  host,  5,  on  local  network  LN(A)  in  country  A,  passes 
through  a  public  network,  PNiA )  in  country  A ,  through  an  in- 
tem*'<ticn4l  network  IN,  through  a  public  network  PN(B)  in 
country  B,  and  finaUy  through  a  local  network,  LNiB),  to  the 
destination  host,  D.  There  are  four  internetwork  gateways 
involved.  It  is  this  model  involving  multiple  pteways  that 
guides  us  away  from  network  interconnection  methods  which 
rely  on  the  source  and  destination  hosts  being  in  adjacent 
networks  connected  by  the  mediation  of  a  single  pteway. 

I)  Common  Subnet  Technology  (Packet  Level  Intercon¬ 
nection):  The  level  at  which  networks  are  interconnected  can 
be  determined  by  the  protocol  layers  terminated  by  the  pte¬ 
way.  For  example,  if  a  pair  of  identical  networks  were  to  be 
interconnected  at  the  interpacket-switch  level  of  protocol, 
we  might  illustrate  the  pteway  placement  as  shown  in  Fig.  8. 
Here  the  "pteway"  may  consist  only  of  software  routines  in 
the  adjacent  packet  switches,  e.g.,  P{A)  and  which  pro¬ 
vide  accounting,  and  possibly  readdressing  functions.  The 
contour  model  of  protocol  layer  is  useful  here  since  it  shows 
which  levels  are  common  to  the  two  networks  and  which 
levels  could  be  different.  In  essence,  these  layers  which  are 
terminated  by  the  gateway.>  could  be  different  in  each  net, 
while  those  which  are  passed  transparently  through  the  pte¬ 
way  are  assumed  to  be  common  in  both  networks.  This  net¬ 
work  interconnection  strategy  requires  that  the  internal  ad¬ 
dress  structure  of  all  the  interconnected  networks  be  common. 
If,  for  example,  addresses  were  composed  of  a  network  identi- 
Her,  concatenated  with  a  packet-switch  identifier  and  a  host 
identifier,  then  addressing  of  objects  in  each  of  the  networks 
would  be  straightforward  and  routing  could  be  performed  on 
a  regional  basis  with  the  network  identifien  acting  as  the 
regional  identifiers,  if  desired.  Alternatively,  two  identical 
networks  could  adopt  a  common  network  name  and  assign 
nonduplicative  addresses  to  each  of  the  packet  switches  in 
both  networks.  This  may  require  that  addresses  in  one  net¬ 
work  be  changed. 

The  strategy  described  above  might  be  called  the  "common 
subnetwork  strategy,"  since,  in  the  end.  subscribers  of  the 
newly  formed  joint  network  would  essentially  see  a  single 
network.  This  strateg)  does  not  rule  out  the  provision  of 
special  access  control  mechanisms  in  the  gate  vry  nodes  which 
could  filter  traffic  flowing  from  one  network  into  the  other. 
Similarly,  the  gateway  nodes  could  perform  special  internet¬ 
work  traffic  accounting  which  might  not  normaUy  be  per¬ 
formed  in  a  subnet  switching  node.  This  network  interconnec¬ 
tion  method  is  limited  to  those  cases  in  which  the  neu  to  be 
connected  are  virtuaUy  identical,  since  the  pteways  must 
participate  directly  in  all  the  subnet  protocols.  The  end-to- 
end  subnet  protocols  (e  g  source/destination  packet-switch 
protocols)  must  pass  transparently  through  the  gateways  to 
permit  interactions  bctwee.n  a  source  packet  switch  in  one 
net  and  a  destination  packet  iwitch  in  another.  The  resulting 
network  presents  the  same  network  access  interface  to  aU 
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lubscriben,  sod  this  leads  us  to  the  next  example  which  is 
based  on  the  concept  of  a  common  network  access  interface. 

2)  Common  Network  Access  Interfeces:  If  the  subnetwork 
protocols  are  not  identical,  the  next  opportunity  to  establish 
internetwork  commonality  is  at  the  network  access  interface. 
This  is  illustrated  in  Fif.  9.  Each  network  is  assumed  to  have 
its  own  intranet  protocols.  However,  each  network  presents 
the  ume  external  interface  to  subscribers.  This  is  illustrated 
by  showing  t  common  interface  passing  through  all  hosts, 
marked  '‘common  network  access  interface"  in  the  figure. 

Once  again,  the  gateway  could  be  thought  of  as  software  in 
adjacent  packet  switches.  Each  pteway  u  composed  of  two 
halves  formed  by  linking  the  packet  switches  of  two  neU 
together.  However,  in  this  case,  the  subnetwork  protocols  arc 
terminated  at  the  pteway  so  that  the  interpteway  cxchtnp 
looks  more  like  network  access  interaction  than  a  node-to- 
node  exchanp.  This  is  the  approach  taken  by  CCITT  with 
its  X.2S  packet  network  interface  recommendation  and  X.7S 
interpteway  cxchanp  recommendation. 

It  is  important  to  note  that  the  interpteway  interface  could 
be  simflar  to  the  standard  network  access  interface,  but  it 
need  not  necessarily  be  identical 

There  are  two  basic  types  of  network  interface  currently  in 
use:  1 )  the  datagram  interface  ( 3 1 1 ;  and  2)  the  virtual  circuit 
interface  (12}.  The  details  of  these  pneric  interface  types 
vary  in  different  networks;  some  networks  even  offer  both 
types  of  interface.  In  some,  the  interface  to  use  may  be 
chosen  at  subscription  time,  in  others  it  may  be  possible  for  a 
subscriber  to  select  the  access  method  dynamicaUy. 


A  datapam  interface  allows  the  subscriber  to  enter  packets 
into  the  network  independent  of  any  other  packets  which 
have  been  or  will  be  entered.  Each  packet  is  handled  separately 
by  the  network.  A  virtual  circuit  interface  requires  an  ex* 
chanp  of  control  information  between  the  subscriber  and  the 
network  for  the  purpose,  for  example,  of  setting  up  address 
translation  tables,  setting  up  routes  or  prcallocating  resources, 
before  any  data  packets  are  carried  to  the  destination.  Some 
networks  may  implement  a  fest  select  virtual  circuit  interface 
in  which  a  circuit  setup  request  is  sent  together  with  the  first 
(and  possibly  last)  data  packet.  Other  control  exchanges 
would  be  used  to  close  the  resulting  virtual  circuits  set  up  in 
this  fashion. 

It  is  essential  to  distinguish  datagram  and  virtual  circuit 
services  from  datapam  and  virtual  circuit  interfaces.  A  data¬ 
gram  service  is  one  in  which  each  packet  is  accepted  and 
treated  by  the  network  independently  of  all  others.  Se¬ 
quenced  delivery  is  not  guaranteed.  Indeed,  it  may  not  be 
guaranteed  that  all  datapams  will  be  delivered.  Packets  may 
be  routed  independently  over  alternate  network  paths.  Dupli¬ 
cate  copies  of  datapams  might  be  delivered. 

Virtual  circuit  service  tries  to  guarantee  the  sequenced  de¬ 
livery  of  the  packets  associated  with  the  ume  virtual  circuit. 
It  typicaUy  provides  to  the  host  advice  from  the  network  on 
flow  control  per  virtual  circuit  at  opposed  to  the  packet-by¬ 
packet  acceptance  or  rejection  typical  of  a  datapam  service, 
if  the  network  operation  might  produce  duplicate  packets, 
these  are  filtered  by  the  destination  packet  twitch  before 
debvery  to  the  subscriber  Dupbeate  packet  creation  is  a 
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common  phenomenon  as  in  packet-switched  itore-and-forward 
systems.  The  basic  mode  of  operation  is  to  forward  a  packet 
to  the  next  switch  and  await  an  acknowledgment.  After  a 
timeout,  the  packet  is  retransmitted.  If  an  acknowledgment  is 
lost  due  to  line  noise,  for  example,  then  two  copies  of  the 
packet  would  have  been  transmitted.  Even  if  the  next  switch 
is  prepared  to  filter  duplicates  out.  a  network  which  uses  adap¬ 
tive  routing  can  deliver  a  duplicate  packet  to  the  periphery  of 
the  network.  For  example,  if  a  packet  switch  receives  a  packet 
successfully  but  the  line  to  the  sender  bieaks  before  the  re¬ 
ceiver  can  acknowledge,  the  sender  may  send  another  copy  to 
a  different  packet  switch.  Both  packet  copies  may  be  routed 
and  delivered  to  the  destination  packet  switch  where  final 
dupUcate  filtering  would  be  needed  if  virtual  circuit  service  is 
being  provided. 

Some  networks  offer  both  a  datagram  and  a  virtual  circuit 
service;  some  offer  a  single  interface,  but  different  servicff. 
For  example,  the  ARPANET  has  a  basic  datagram  interface. 
However,  the  subnetwork  will  automatically  provide  a  se¬ 
quenced  vinual  circuit  service  (i.e..  packets  are  kept  in 
sequence  when  they  are  delivered  to  the  destination)  if  the 
packet  is  marked  appropriately.  Otherwise,  packets  are  not 
delivered  in  sequence  nor  arc  packet  duplicates  or  losses, 
except  for  line  by  link  correction,  recovered  within  the  net¬ 
work  for  nonscquenced  types  of  traffic. 

By  contrast.  TRANSPAC  offers  a  virtual  circuit  interface 
and  service.  Subscribers  transmit  *’caU  request"  packeu 
containing  the  full  destinatirm  address  to  the  packet  switch. 
The  request  packet  is  forwarded  to  the  destination,  leaving 
behind  a  fixed  route.  The  destination  subscriber  returns  a 
"call  accepted"  packet  which  is  delivered  to  the  caUcr.  As  a 


result  of  this  exchuge.  the  source  subscriber  has  associated  a 
“logical  channel  number"  or  LCN,  with  the  full  source- 
destination  addresses.  Thus  subsequent  packeu  to  be  sent  on 
the  ume  logical  channel  are  identified  by  the  LCN  and  are 
kept  in  sequence  when  delivered  to  the  destination. 

FinaUy,  it  is  possible  to  implement  a  datagram-like  service 
using  a  virtual  circuit  interface,  in  this  case,  the  exchange  of 
request  and  accept  packets  might  be  tenniruted  at  the  sub¬ 
scriber's  local  packet  switch,  so  that  even  if  packets  were  not 
delivered  in  sequence  they  might  employ  abbreviated  address¬ 
ing  for  local  subscriber  and  packet-switch  interaction. 

If  network  interaction  is  to  be  based  on  a  standard  interface, 
then  agreement  must  be  reached  both  on  the  interface  and  an 
associated  service  or  services.  Furthermore,  a  common  ad¬ 
dressing  system  is  needed  so  that  a  subscriber  on  one  network 
can  address  a  packet  to  a  subscriber  on  any  other  network.  A 
weaker  ammption  could  be  made  but  we  are  deliberately 
assuming  a  truly  common  service,  interface,  and  addressing 
mechanism.  We  will  return  to  this  topic  in  a  later  section. 

The  choice  of  a  standard  network  service  through  which  to 
effect  network  intercrmnection  has  a  primary  impact  on  the 
flexibility  of  implementable  network  interconnection  methods. 
We  will  consider  two  choices:  datagram  service  and  virtual 
circuit  service. 

a)  Datasram  service  as  a  standard  for  network  intercon- 
nection:  For  this  cam,  it  is  assumed  that  every  network  offers 
a  common  da:tgram  service.  A  uniform  address  space  makes  it 
possible  for  ?vbscribcrs  on  any  network  to  send  packets  ad¬ 
dressed  to  an,''  r  Uirr  subscriber  on  a  connected  network.  Pac¬ 
kets  arc  routed  between  subscriber  and  gateway  and  between 
pteways  based  on  the  destination  address.  No  attempt  is 
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made  to  keep  the  datagrams  in  any  order  in  transit  or  upon  de* 
livery  to  the  destination.  Individual  datagrams  may  be  freely 
routed  through  different  gateways  to  recover  from  failures  or 
to  allow  load-splitting  among  parallel  gateways  joining  a  pair 
of  networks. 

The  gateway/gateway  interface  may  be  different  than  the 
network  access  interface,  if  need  be  (see  Fig.  9). 

This  strategy  requires  that  all  networks  implement  a  com¬ 
mon  interface  for  subscribers.  The  simplicity  and  flexibility 
of  the  datagram  interface  strategy  is  offset  somewhat  by  the 
need  for  all  networks  to  implement  the  same  interface.  This  is 
true  for  the  pure  virtual  circuit  interface  strategy  as  well,  as 
wiU  be  shown  below. 

One  of  the  problems  which  has  to  be  faced  with  any  net¬ 
work  interconnection  strategy  is  congestion  control  at  the 
gateways.  If  a  gateway  finds  that  it  is  unable  to  forward  a 
datagram  into  the  next  network,  it  must  have  a  way  of  reject¬ 
ing  it  and  quenching  the  How  of  traffic  entering  the  gateway 
en  route  into  the  next  network.  The  quenching  would  typi¬ 
cally  take  the  form  of  an  error  or  flow  control  signal  passing 
from  one  gateway  half  to  another  on  behalf  of  the  associated 
network.  Similar  signals  could  be  passed  between  subscribers 
and  the  packet  network  for  similar  reasons.  Since  datagram 
service  does  not  undertake  to  guarantee  end/end  reliability, 
it  is  possible  to  relieve  momentary  congestion  by  discarding 
datagrams,  as  a  last  resort. 

bj  Virtual  circuits  for  network  interconnection:  Another 
alternative  standard  network  service  which  could  be  used  for 
network  interconnection  is  virtual  circuit  service  (Fig.  10). 
Independent  of  the  precise  interface  used  to  *‘set  up"  the 
virtual  circuit,  a  number  of  implementation  issues  immedi¬ 
ately  arise  if  such  a  service  is  used  as  a  basis  for  network 
interconnection. 

Since  it  is  intended  that  all  packets  on  a  virtual  circuit  be 
delivered  to  the  dest  nation  subscriber  in  the  same  sequence 
as  they  were  entered  by  the  source  subscriber,  it  is  necessary 
that  either:  1)  all  packets  belonging  to  the  same  virtual  circuit 
take  the  same  path  from  source  subscriber,  through  one  or 
more  pteways,  to  destination  subscriber;  or  2)  all  packets 
contain  sequence  numbers  which  are  preserved  end-to-end 
between  the  source  DCE  in  the  originating  network  and  the 
destination  DCE  in  the  terminating  network. 

In  the  flnt  case,  virtual  circuits  are  set  up  and  anchored  to 
specific  gateways  so  that  the  sequencing  of  the  virtual  circuit 
service  of  each  network  can  be  used  to  preserve  the  packet 
sequence  on  delivery.  This  results  m  the  concatenation  of  a 
series  of  virtual  circuits  through  each  pteway  and.  therefore, 
the  knowledge  of  each  virtual  circuit  at  each  gateway  (since 
the  next  pteway  to  route  the  packet  through  must  be  fixed 
for  each  virtual  circuit). 

In  the  second  case,  there  is  no  need  to  restrict  the  choice  of 
pteway  routing  for  esch  virtual  circuit  smee  the  destination 
DCE  will  have  sufficient  information  to  resequence  incoming 
packets  prior  to  delivery  to  the  destination  subscriber. 

In  either  case,  the  destination  DCE  will  have  to  buffer  and 
resequence  packets  arriving  out  o'  order  due  either  to  dis¬ 
ordering  within  the  last  network  or  to  alternate  routing  among 
networks,  if  this  is  permitted.  Some  networks  may  keep 
packets  in  sequence  as  they  transit  the  network.  This  will  only 
be  advantapous  at  the  destination  DCE  if  the  packets  enter 
the  network  in  the  desired  sequence.  If  such  a  service  is  relied 
upon  in  the  internet  e.i.ironment,  then  each  gatewey  must 
assure  that  on  entry  to  such  a  net.  the  packets  are  in  the  de- 
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Fig.  10.  Virtual  circuit  network  interconnection  strategict.  (a)  Sub- 
tcriber-based  gateway.  Internet  source  and  destination  carried  in  user 
data  field  of  X.2S  call  set-up  packets,  (b)  X.75  based  gateway.  Note 
how  much  of  the  X.2S  VC  Krvtce  is  terminated  at  the  STE.  (c)  X.7S- 
baaed  gateways  with  general  virtual  circuit  networks. 


sired  order  for  delivery  to  a  destination  subscriber  or  another 
gateway. 

The  buffering  and  resequencing  of  packets  within  the  net¬ 
works  or  at  pteways  introduces  substantial  variation  in  buffer 
space  requirements,  packet  transit  delays,  and  the  potential  for 
buffer  lockups  to  occur  ( SO] ,  ( S 1  ] ,  (6 1 ) . 

If  packets  for  a  specific  virtual  circuit  are  restricted  to  pass 
through  a  fixed  series  of  gateways,  and  if  a  standard  flow- 
control  method  is  agreed  upon  as  part  of  the  virtual  circuit 
service,  then  it  is  possible  for  each  internet  gateway  to  partici¬ 
pate  in  end-to-end  flow  control  by  modifying  the  flow  control 
information  carried  in  packets  carried  end-to-end  from  the 
source  DCE  to  the  destination  DCE.  Consequently,  a  gate¬ 
way  may  be  able  to  adjust  the  amount  of  traffic  passing 
through  it  and  thereby  achieve  a  kind  of  internet  gateway 
congestion  control.  If  this  is  done  by  allocating  buffer  space 
for  "outstanding"  packets,  then  either  the  gateways  must 
guarantee  the  advertised  buffer  space  or  there  must  be  a  re¬ 
transmission  capability  built  into  the  internet  virtual  circuit 
implementation,  perhaps  between  source  DCE  and  destination 
DCE  or  between  DCE's  and  gateway*. 

Such  a  mechanism  does  not.  however,  solve  the  problem  of 
network  congestion  unless  the  gateway-flow  control  decisions 
take  into  account  resources  both  in  the  gateway  and  in  the 
rest  of  the  network.  Although  it  is  templing  to  assume  that 
virtual  circuit-flow  control  can  achieve  iniemetwork  conges¬ 
tion  control,  this  is  by  no  means  clear,  and  is  still  the  subject 
of  considerable  research. 

As  a  general  rule,  compared  to  the  datagram  method,  the 
virtual  circuit  approach  requires  more  state  information  in 
each  gateway,  since  knowledge  of  each  virtual  circuit  must  be 
maintained  along  -ith  flow  control  and  routing  information 
The  usual  virtual  ctcuiI  interface  is  somewhat  more  complex 
for  subsenbers  to  implement  as  well,  because  of  ihe  amount 
of  state  information  which  must  be  shared  by  the  subscriber 
and  the  local  DCE  For  example,  implementaticns  of  the  .X.25 
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intcfface  protocol  have  been  privately  reported  by  Computer 
Corporation  of  America  and  Univereity  College  London  to 
require  4000-8000  words  of  memory  on  Digital  Equipment 
Corporation  PDF  11  computers.  By  contrast,  the  ARPANET 
and  Packet  Radio  Network  datagram  interfaces  require  SOO- 
1000  words  of  memory  on  the  same  machine.  For  internet* 
work  operation,  this  may  be  even  more  burdensome,  since 
any  failure  at  a  gateway  may  require  a  subscribcHevel  re¬ 
covery  through  an  end-to-end  protocol,  in  addition  to  the 
virtual  circuit  interface  software,  as  is  shown  in  ( 52] . 

Nevertheless,  it  may  be  advantageous  to  consider  internet¬ 
working  standards  which  usefully  employ  both  datagram  and 
virtual  circoil  interfaces  and  services.  For  example,  some 
special  infemtt  services  such  as  multidestination  delivery  may 
be  more  efficient  if  they  are  first  set  up  by  control  exchanges 
between  the  subscriber  and  the  local  network  and  perhaps 
gateways  as  well.  Once  set  up,  however,  a  datagram  mode  of 
operation  may  be  far  more  efficient  than  maintaining  virtual 
circuits  for  all  destinations  Implicit  virtual  circuits  which  arc 
activated  by  simple  datagram-like  interfaces  arc  also  attrac¬ 
tive  for  very  simple  kinds  of  terminal  equipment. 

If  it  is  not  possible  for  all  networks  to  implement  a  common 
network-acceu  interface,  then  the  next  opportunity  is  to 
standardize  only  the  objects  which  pass  from  one  net  to  the 
nest  and  to  minimize  any  requirements  for  the  Kqucncing 
of  these  objects  as  they  move  from  net  to  net 

J)  Genera!  Host  Gateways  In  this  model,  a  gateway  u 
indistinguishable  from  any  other  network  host  and  will  imple¬ 
ment  whatever  host/network  interface  is  required  by  the 
networks  to  which  it  is  attached  For  many  networks,  this 
may  be  X.25.  but  the  strategy  does  not  rely  on  this  The 
principle  auumption  is  that  packet  networks  are  at  least 
capable  of  carrying  subscriber  packets  up  to  some  maximum 


length,  which  may  vary  from  network  to  network.  It  is  specif¬ 
ically  not  assumed  that  these  packets  will  be  delivered  in  order 
through  intermediate  networks  and  gateways  to  the  destina¬ 
tion  host.  This  minimal  type  of  service  is  often  termed  **data- 
gram”  service  to  distinguish  it  from  sequenced  virtual  circuit 
service.  A  detailed  discussion  of  the  tradeoff  between  data¬ 
gram  and  virtual  circuit  types  of  networks  is  given  elsewhere 
(521. 

The  basic  model  of  network  interconnection  for  the  data¬ 
gram  host  pteway  is  that  internetwork  datagrams  will  be 
carried  to  and  from  hosts  and  pteways  and  between  pteways 
by  encapsulation  of  the  datapams  in  local  network  packets. 
Pouzin  describes  this  process  gcnerically  as  "wrapping**  [37]. 
The  basic  internetwork  service  is  therefore  a  datagram  Be^ 
vice  rather  than  a  virtual  circuit  service.  The  concept  is 
illustrated  in  Fig.  1 1. 

Datapam  service  docs  not  offer  the  subscriber  as  many 
facilities  as  virtual  circuit  service.  For  example,  not  all  data- 
pams  are  guaranteed  to  be  delivered,  nor  do  those  that  are 
delivered  have  to  be  delivered  in  the  sequence  they  were  sent. 
Virtual  circuits,  on  the  other  hand,  do  attempt  to  deliver  all 
packets  entered  by  the  source  in  sequence  to  the  destination. 
These  relaxations  aUow  dynamic  routing  of  datapams  among 
multiple,  internetwork  gateways  without  the  need  fos  sub¬ 
scriber  intervention  or  alert. 

The  internet  datapam  concept  gives  subscriters  access  to  a 
basic  internet  datapam  service  while  allowing  them  to  build 
more  elaborate  end-to-end  protocols  on  top  of  it.  Fig.  12 
illustrates  a  possible  protocol  hierarchy  which  could  be  baaed 
on  the  internet  datapam  concept  The  basic  internet  data¬ 
gram  service  could  be  used  to  support  uansacbon  protoc<^ 
or  real-time  protocob  (RTF)  such  as  packet-voice  protocob 
(PVP)  which  do  not  require  guaranteed  or  sequenced  data 
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delivery,  reliable,  sequenced  protocols  could  be  constructed 
above  the  basic  internet  datafram  service  to  perform  end/end 
scquencinf  and  error  handling.  Applications  such  u  virtual 
terminal  protocols  (VTP)  (40),  (42),  (48)  or  rUe-traiufer 
protocols  (40).  (42),  (49)  could  be  built  above  a  reliable, 
point-to-point,  end/end  service  whtch  is  itMlf  built  atop  inter- 
net  datatrama  Under  this  strategy,  the  basic  gateway  func¬ 
tions  arc  the  encapsulation  and  decapsulation  of  datagrams, 
mapping  of  mtemet  source/destirution  addresses  into  local 
network  addresses  and  datagram  routing.  Gateways  need  not 
have  any  knowledge  of  higher  level  protocob  if  it  b  assumed 
that  protocob  above  the  internet  datagram  layer  are  held  in 
common  by  the  communicating  hosts.  Datagrams  can  be 
routed  freely  among  gateways  and  can  be  delivered  out  of 
sequence  to  the  drstirution  hosL 
The  basic  advantage  of  this  strategy  is  that  almost  any  sort 
of  network  can  participate,  whether  its  internal  operation  is 
datagram  or  virtual  circuit  onented.  Furthermore,  the  strategy 


offers  an  easy  way  for  new  networks  to  be  made  “backwards 
compatible,"  with  older  ones  while  allowing  the  new  ones  to 
employ  new  internal  operations  which  are  innovative  or  more 
cfricicnt. 

Every  subscriber  must  implement  the  internet  datagram  con¬ 
cept  for  this  strategy  to  work,  of  course.  The  same  problem 
arises  with  the  standard  network  interface  strategy  since  all 
subscribers  must  implement  the  same  network  interface. 

4}  ^otocoi  Tranjlahon  G«teways:  It  would  be  misleading 
to  claim  that  the  concept  of  protocol  translation  has  not 
played  a  role  in  the  discusuon  thus  far.  in  a  sense,  the  encap¬ 
sulation  of  internet  datagrams  in  the  packet  format  of  each 
intermediate  network  is  a  form  of  protocol  translation.  The 
basic  packet  carrying  service  of  one  network  u  being  trans¬ 
lated  info  the  next  network's  packet  carrying  service  (tee  Fig 
13).  Thu  concept  could  be  extended  further  For  cxampic, 
if  two  networks  have  a  virtual  cirern:  concept,  one  imple¬ 
mented  within  the  subnetwork  and  the  other  through  common 
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host/host  protocols,  it  might  be  possible,  at  the  gateway  be* 
tween  the  nets,  to  map  one  network’s  virtual  circuit  into  the 
other’s.  This  same  idea  could  be  applied  to  higher  level  proto¬ 
col  mappings  as  well;  for  instance,  the  virtual  terminal  proto¬ 
col  for  one  network  might  be  transformed  into  that  of  another 
“on  the  fly.” 

The  success  of  such  a  translation  strategy  depends  in  large 
part  on  the  commonality  of  concept  between  the  protocols 
to  be  translated.  Mismatches  in  concept  may  require  that  the 
service  obtained  in  tne  concatenated  case  be  a  subset  of  the 
services  obtainable  from  either  of  the  two  services  being  trans¬ 
lated.  Extending  such  translations  through  several  gateways 
can  be  difficult,  particularly  if  the  protocols  being  tra  islated 
do  not  share  a  common  address  space  for  internetwork  sources/ 
destinations.  In  the  extreme,  this  strategy  can  result  in  sub¬ 
scribers  ’logging  in”  to  the  gateway  in  order  to  activate  the 
protocols  of  the  next  network.  Indeed,  front-end  computers 
could  be  considered  degenerate  translation  gateways  since  they 
transform  host/front-end  protocols  into  network  protocols. 

There  are  circumstances  when  translation  cannot  be  avoided. 
For  instance,  when  the  protocols  of  one  network  cannot  be 
modified,  but  internet  service  is  desired,  there  may  be  no 
titemative  but  to  implement  protocol  translations.  The  model 
typically  used  to  guide  protocol  translation  gateways  is  that 
the  iource/dcstination  hosts  lie  on  either  side  of  the  transla¬ 
tion  gateway.  Concatenation  of  protocol  translations  through 
several  networks  end  gate;''ays  is  conceivable,  but  may  be  very 
difficult  in  practice  and  may  produce  very  inefficient  unrice. 

C  Namet,  Addrustt,  and  Routes 

In  order  to  manage,  control,  and  support  communication 
among  computers  on  one  or  more  networks,  it  is  essential  that 
conventicni  be  established  for  identifying  the  communicaton. 
For  purposes  of  this  discussion,  we  will  use  the  term  host  to 
refer  to  all  computers  whici.  attach  to  a  network  at  (he  net¬ 
work- access  level  of  protocol  (sec  Table  I).  Subscribers  to 
terminal- access  services  can  be  thought  of  as  attaching  to  hosts, 
even  if  the  host  is  embedded  in  the  hardware  and  software  of 
a  packet  switch  as  a  layer  of  protocol.  Consequently,  we  can 
uy  that  the  basic  task  of  a  packet-switching  network  is  to 
transport  data  from  a  source  host  to  one  or  more  destination 
hosts. 

To  accomplish  this  task,  each  network  needs  to  know  to 
which  destination  packets  are  to  be  delivered.  Even  in  broad¬ 
cast  nets  such  u  the  ETHERNET,  this  information  is  neccs- 
ury  so  that  the  desimation  host  can  discriminate  packets 
destined  for  itself  from  all  othen  heard  on  the  net.  At  the 
lowest-protocol  levels  it  u  typical  to  associate  destinations 
with  addreues.  An  addreas  may  be  simply  an  integer  or  it 
may  have  more  internal  structure. 

At  higher  levels  of  protocol,  however,  it  is  more  common  to 
find  text  strings  such  as  “MULTICS”  or  “BBN-TENEX”  uKd 
as  names  of  destinations.  Appbcation  software,  such  as  elec¬ 
tronic  mail  services,  might  employ  aich  names  along  with 
more  refined  destination  identifiers.  For  example,  one  of  the 
authors  has  an  electronic  mailbox  named  “KIRSTEIN  at  1$!“ 
located  in  a  computer  at  the  University  of  Southern  Cahfomia's 
Information  Sciences  Institute. 

Typically,  application  programs  transform  names  into  ad¬ 
dresses  which  can  be  understood  by  the  packetHwitching  net¬ 
work.  The  networks  must  transform  these  ridrvBes  into 
routes  to  guide  the  packets  to  then  destination  Some  net¬ 
works  bind  addreues  to  routes  in  a  relatively  x»$sA  way  (ej.. 


setting  up  virtual  circuits  with  flxed  routing)  while  others 
determine  routes  as  the  packets  move  from  switch  to  switch, 
choosing  alternate  routes  to  bypass  failed  or  congested  areas  of 
the  network.  Broadcast  networks  need  not  create  routes  at  all 
(e^..  SATNET) 

In  simple  terms,  a  name  tells  what  an  object  is;  an  address 
tells  where  it  is;  and  a  route  tells  >^0/  to  get  there  (54],  A 
simple  model  involving  these  three  concepts  is  that  hosts  trans¬ 
form  names  into  addresses  and  networks  transform  addresses 
into  routes  (if  necessary).  However,  this  basic  model  docs  leave 
a  Urge  number  of  loose  ends.  The  subject  is  so  filled  with 
issues  that  it  is  not  po.iJbte  in  this  paper  to  explore  them  all  in 
depth.  In  what  foUovs,  mjirs  of  the  mejor  issues  are  raised 
and  some  partial  resolutions  are  offered. 

One  m«jor  question  is  “Which  objects  in  the  network  should 
hn«e  names?  addresses?”  Pouzin  and  2^mmermann  offer  a 
nirmber  of  views  on  this  question  in  their  paper  in  this  issue 
(37] .  A  generic  answer  might  be  that  at  least  all  objects  which 
can  be  addressed  by  the  network  should  have  names  as  well  so 
t^at  high-level  protocols  can  refer  to  them.  For  example,  it 
might  be  reasonable  for  every  host  connection  on  the  network 
to  have  an  name  and  an  addreu.  There  also  may  be  objects 
interna!  tu  the  network  which  also  have  addreues  such  as  the 
statistics^ athering /ake  fiosts  in  the  ARPANET  (38]. 

A  reUted  iuue  is  whether  objects  should  or  can  have  multiple 
names,  multiple  addresses,  and  multiple  routes  by  which  they 
can  be  reached.  The  most  genera!  resolution  of  this  issue  is  to 
permit  multiple  names,  addresses,  and  routes  to  exist  for  the 
same  object.  An  example  taken  from  the  multinetwork  en¬ 
vironment  may  serve  to  illustrate  this  notion.  Fig.  6  shows 
three  networks  which  arc  interconnected  by  a  number  of  gate¬ 
ways.  Each  gateway  (or  pair  of  gateway  halves)  has  two  inter¬ 
faces,  one  to  each  network  to  which  it  is  attached.  Plainly 
there  is  the  possibihty  that  several  alternate  routes  panuig 
through  different  gateways  and  networks  could  be  used  to 
carry  packets  from  a  source  host  in  one  net  to  a  destination 
host  in  another  net.  This  is  just  the  analog  of  alternate  routing 
within  a  tingle  network 

Furthermore,  each  gateway  has  two  addresKS.  typically  one 
for  each  attached  network.  Thu  is  just  the  analog  of  a  host  on 
one  network  attached  to  two  or  more  packet  twitches  for  reli¬ 
ability.  The  term  mulrihcminf  is  often  used  to  refer  to  mul¬ 
tiply  attached  hosts. 

Finally,  ii  may  be  useful  to  permit  a  gateway  to  have  more 
than  one  name,  for  exampic,  one  for  each  network  to  which  it 
u  attached.  This  might  allow  high-level  protocols  to  force 
packets  to  be  routed  in  certain  ways  for  diagnostic  or  other 
reasons.  Multiple  naming  also  allows  the  use  of  nicknames  for 
user  convenience.  Many  of  there  same  comments  would  apply 
to  hosts  attached  to  multiple  networks. 

An  interesting  addressing  and  routing  problem  arises  in  mo¬ 
bile  packet  radio  networks.  StAcx  hosts  art  free  to  move  about, 
the  network  will  need  to  dynamically  chtnte  the  routeauaed  to 
reach  each  host.  For  robustness,  it  u  alto  desirable  that  hosts 
be  able  to  attach  dynamically  io  different  packet  ladiot.  Thus 
failure  of  a  packet  radio  need  not  Kevent  hosts  from  accesmng 
the  network.  Thu  requires  (hat  host  names  and  perhaps  host 
address  ^  be  decoupled  from  packet  radio  addreams.  The  net¬ 
work  mu$  be  able  to  search  for  hosts  or  alternatively,  ho«t 
mutt  “rer  r’.-in"  to  the  network  so  that  theu  addresKt  can  be 
ataocuied  h  the  attached  packet  radio  to  faciliiatc  route 
selection  based  on  host  addreu.  Thu  is  just  a  way  of  sup|ion- 
ing  lognal  host  addressing  rather  than  using  the  more  conunon 
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physical  host  addressing  in  which  a  host’s  address  is  an  exten¬ 
sion  of  the  packet-switch  address. 

A  crucial  issue  in  network  interconnection  is  the  extent  to 
which  it  should  or  must  impact  addressing  procedures  which 
are  idiosyncratic  to  a  particular  network.  It  is  advantageous 
not  to  require  the  subscribers  on  each  network  to  have  detailed 
knowledge  of  the  network  address  structure  of  all  intercon¬ 
nected  networks.  One  possibility  is  to  standardize  an  internet¬ 
work  address  structure  which  can  be  mapped  into  local  net¬ 
work  addresses  as  needed,  either  by  subscribers,  by  gateways 
or  by  both.  Subscribers  would  know  how  to  map  internetwork 
service  names  into  addresses  of  the  form  NETWORK/SERVER. 
Subscribers  need  not  know  the  fine  structure  of  the  SERVER 
Held.  Gateways  would  route  packets  on  the  basis  of  the  NET¬ 
WORK  part  of  the  address  until  reaching  a  gateway  attached 
to  the  network  identified  by  NETWORK.  At  this  point,  the 
gateway  might  interpret  the  SERVER  part  of  the  address,  as 
necessary,  to  cause  the  packet  to  be  delivered  to  the  desired 
host. 

The  addressing  strategy  presently  under  consideration  by 
CCITT  (X.I21,  (301)  is  based  on  the  telephone  network.  Up 
to  14  digits  can  be  used  in  an  address.  The  f^  4  dt«!ts  arc  a 
“destination  network  identification  code"  or  DNiC.  Some 
countries  are  allocated  more  than  one  DNIC  (the  United  States 
has  200).  The  remaining  ten  digits  may  be  used  to  implement 
a  hierarchical  addressing  structure,  much  like  the  one  used  in 
the  existing  telephone  network. 

Since  the  CCITT  agreements  are  for  international  operation, 
it  might  be  ftv  to  assume  that  the  United  States  will  not  need 
more  than  200  public  network  identifien.  However,  this 
scheme  does  not  take  into  account  the  need  for  addressing 
private  networks.  The  private  networks,  under  this  addressing 
procedure  will  most  likely  appear  to  be  a  collection  of  one  or 
more  terminals  or  host  computers  on  one  or  more  public  net¬ 
works.  It  is  too  early  to  tell  how  much  this  asymmetry  in  ad¬ 
dressing  between  public  and  private  networks  will  affect  private 
mult  inet work  protocols. 

A  related  problem  which  is  not  unique  to  network  intercon¬ 
nection  has  to  do  with  addressing  (really  multiplexing  and  de¬ 
multiplexing)  at  higher  protocol  levels.  The  public  camcn 
tend  to  offer  services  for  terminal  as  well  as  host  access  to  net¬ 
work  facilities.  This  typically  means  that  addresses  must  be 
assigned  to  terminals.  The  issue  U  whether  the  terminal  address 
should  be  asvKuted  with  or  independent  of  the  protocols 
used  to  support  terminal-to-host  commurucation. 

The  present  numbering  scheme  would  not  distinguish  be¬ 
tween  a  host  address  and  a  terminal  addreu.  A  host  muthi 
have  many  addresses,  each  corresponding  to  a  process  waiting 
to  service  calling  terminals. 

There  has  been  discussion  within  CCITT  concerning  “subad- 
dressir.g’*  through  the  use  of  a  user  data  field  earned  in  virtual 
call  “setup”  packets  This  notion  would  support  the  concept 
ot  a  single  host  address  with  terminal  or  process  level  demulti¬ 
plexing  achieved  through  the  use  of  the  user  data  field  sub- 
addreasing. 

It  seems  reasonable  to  predict  that,  as  terminals  increase  in 
complexity  and  capability,  it  wiU  eventually  be  attractive  to 
Support  multiple  concurrent  associations  between  the  terminal 
and  several  remote  lervice  facilities.  Applications  requumg 
this  capability  will  need  terminal  multiplexi.ng  conventions 
beyond  ihoK  currently  provided  for  in  the  CCITT  recommen¬ 
dations. 
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To  simplify  implementations  of  internet  protocol  software, 
it  is  essential  to  place  bounds  on  the  maximum  size  of  the 
NETWORK/SERVER  address.  Otherwise,  subscribers  may 
have  to  construct  name-to-address  mapping  tables  wHh  arbi¬ 
trarily  large  and  complex  entries. 

Even  if  sU  these  issues  are  resolved,  there  is  still  a  question  of 
“source  routing”  in  which  a  subscriber  defines  the  route  to  be 
taken  by  a  particular  packet  or  virtual  circuit.  Depending  on 
the  range  of  internetwork  services  available,  a  subscriber  may 
want  to  control  packet  routes.  It  is  not  yet  clear  how  such  a 
capability  will  interact  with  access  control  conventions,  but 
this  may  be  a  desirable  capability  if  gateways  are  not  able  to 
automatically  select  routes  which  match  user  service  require- 
mcfits. 

D.  Flow  and  Congeition  Control 

For  purposes  of  discussion,  we  distinguish  between  flow  and 
congestion  control.  Flow  control  is  a  procedure  through  which 
a  pair  of  communicators  regulate  traffic  flowing  from  source 
to  destination  (each  direction  possibly  being  dealt  with  sepa¬ 
rately).  Congestion  control  is  a  procedun  whereby  d.istributed 
network  resources,  such  as  channel  bandwidth,  buffer  capacity, 
CPU  capacity,  and  the  like  are  protected  from  oversubscrip¬ 
tion  by  all  sources  of  network  traffic.  In  genera.1.  the  succeu- 
ful  operation  of  flow-control  procedures  for  every  pair  of  net¬ 
work  communicants  does  not  guarantee  that  the  network 
resources  will  remain  uncongested. 

In  a  single  network,  the  control  of  flow  and  congestion  is  a 
complex  and  not  well  understood  problem.  In  s  multinetwork 
environment  it  is  even  more  complex,  owing  to  the  possible 
vanationi  ui  flow  and  congestion  control  policies  found  in 
each  constituent  network.  For  example,  some  networks  may 
ngidly  control  the  input  of  packets  mto  the  network  and  ex¬ 
plicitly  rule  out  dropping  packets  zs  a  means  of  congeiiion 
control.  At  the  other  extreme,  some  networks  may  drop 
packets  as  the  sole  means  of  congestion  control. 

At  this  stage  of  development,  very  little  U  known  about  the 
behavior  of  congestion  in  multiply  interconnected  networks. 
It  is  clear  that  some  mechanisms  will  be  required  which  permit 
gateways  and  networks  to  assert  conitol  over  traffic  influx  es¬ 
pecially  when  a  gateway  connects  networks  o'  widely  varying 
capacity.  Thn  problem  a  likely  lo  be  most  visible  al  gateways 
)oining  high  speed  local  networks  to  long-haul  public  nets 
The  peak  rates  of  the  local  nets  might  exceed  that  of  the  long- 
haul  nets  by  facton  of  30-100  or  more.  Generic  procedures 
are  needed  for  gateway /network  and  gateway/gateway  flow 
and  congestion  control.  Such  problems  also  show  up  in  singie 
networks,  but  are  amplified  in  the  multinetwork  case. 

£.  Aceeuf-ting 

Accounting  for  internetwork  traffic  is  an  important  proS 
lem.  The  pubbe  networks  need  mrcharusmt  for  feveiii.e  shar¬ 
ing  and  subserbrrs  need  simple  procedures  for  verifying  the 
accuracy  of  net  work -pro sided  accountings. 

The  pubbe  packet-switching  networks  appear  to  be  couvers- 
ing  on  procedures  which  account  !«.<  s-tbsenber  use  on  the 
basis  of  the  number  of  virtual  circuits  created  dunng  the  ac¬ 
counting  period  and  the  number  of  packets  sent  oneaih  virtual 
circuit.  Indeed,  it  has  been  argued  that  accounting  on  the 
baio  of  virtual  circuits  al  gateways  requires  leu  overhead  than 
accounting  o.n  a  pure  datagram  baus  (32)  .  Scenarios  can  Ne 
Cited  which  wpport  the  opposite  conclusion 


3-115 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1985 


CERF  AND  KIRSTEIN:  ISSUES  IN  PACKET  NETWORK  INTERCONNECTION  1401 


Suppose  there  is  a  choice  between  setting  up  virtual  circuits 
for  each  transaction  and  sending  a  datagram  for  each  transac¬ 
tion,  and  that  vHuai  circuit  accounting  includes  information 
on  each  virtual  circuit  setup  (as  in  the  present  telephone  net¬ 
work).  If  datagram  accounting  simply  accumulates  the  number 
of  datagrams  sent  between  particular  sources  and  destinations 
without  regard  to  the  time  at  which  they  are  sent,  then  the 
amount  of  accountirtg  information  which  Ls  collected  for  the 
datagram  case  will  be  substantially  less  than  for  the  virtual 
circuit  case.  In  the  limil  (i.e.,  one  packet  per  transaction),  the 
virtual  circuit  accounting  iniormation  is  proportional  to  2N, 
where  N  is  the  number  of  trai  :i:.ctions,  while  for  the  datagram 
case,  it  is  propoitional  to  log  N  (base  2).  This  is  simply  because 
the  datagram  case  only  sums  counts  for  traffic  between  source/ 
destination  pairs  while  the  virtual  circuit  accounting  would 
identify  start/stop  times  for  each  virtual  circuit. 

Alternatively,  if  the  bulk  of  the  traffic  involves  a  large  num¬ 
ber  of  packets  per  transaction,  then  the  two  accounting  pro¬ 
cedures  would  accumulate  more  nearly  the  same  information 
since  each  would  predominantly  involve  accounting  for  packet 
flow. 

If  it  is  chosen  not  to  account  for  virtual  circuit  duration,  but 
merely  to  account  independently  for  the  number  of  virtual 
circuits  and  the  number  of  packets  sent  between  source/desti¬ 
nation  paiis,  then  the  virtual  circuit  accounting  would  be  closer 
to  the  datagram  case. 

The  important  conclusion  to  be  drawn  is  that  accounting  for 
datagrams  is  generally  less  complex  than  accounting  for  virtual 
circuits,  but  that  the  two  can  be  made  arbitrarily  similar  by 
suitable  choice  of  the  details  of  the  accounting  infc<mation 
collected. 

F.  Access  Control 

In  multinetwork  environments,  it  may  be  necessary  for  each 
network  to  establish  and  enforce  a  policy  for  “out-of-network” 
routing.  For  example,  a  public  network  might  conclude  agree¬ 
ments  with  other  networks  regarding  the  type  and  quantity  of 
traffic  It  will  forward  into  other  networks.  This  might  even  be 
a  function  of  the  time-of-day.  Consequently,  mechanisms  are 
needed  whiCh  will  permit  networks  to  prevent  traffic  from 
entering  or  leaving  or  to  meter  the  type  and  rate  of  traffic 
passing  into  or  out  of  the  network. 

Another  example  of  the  need  for  control  arises  with  the  posr 
sibility  of  third-party  routing.  That  is,  tiiffic  destined  from 
network  A  to  network  B  is  routed  through  network  C.  It  can¬ 
not  be  assu.  .ed  that  all  .i  works  have  gateways  to  all  others. 
However,  some  nets  may  want  to  limit  the  amount  of  transit 
traffic  they  carry.  There  may  be  expLcit  agreements  among  a 
subset  of  the  nets  regarding  revenue  sharing  for  transit  services. 
If  a  particular  network  does  not  nave  •  revcnue-shaimg  agree¬ 
ment  with  the  particular  source/destination  networks  of  a 
given  virtual  circuit  or  datagram,  then  it  must  be  able  to  reject 
the  offending  traffic  if  it  so  chooses. 

There  does  not  seem  to  be  any  technical  barrier  tc  separating 
the  access  control  poLcy  decision  mechanism  from  vhe  enforce¬ 
ment  of  the  policy.  For  example,  a  gateway  might  rimply  en¬ 
force  policy  by  sending  traffic  for  which  it  has  no  known  ac¬ 
cess  rules  to  an  access  controller.  If  we  adhere  to  the  model 
that  gateways  have  two  halves,  then  each  half  deals  with  the 
network  to  which  it  is  connected.  The  access  controller  can 
either  dynamically  enable  the  flow  by  causing  table  entries  at 
the  g?«eways  which  permit  the  flow  to  be  created  or  it  can  tell 
the  gateway  to  reject  all  further  traffic  of  that  type. 


Clearly,  access  control  policies  wiU  affect  routing  strategies, 
so  this  adds  a  complicating  factor  into  any  internetwork  rout¬ 
ing  strategy  implemented  by  the  gateways.  At  present,  very 
little  experience  has  been  accumulated  with  internet  access 
control  and  routing  policies.  For  the  most  part,  agreements 
among  public  networks  have  been  bilateral  and  transit  routing 
has  been  treated  as  a  very  special  case.  When  EURONET  (6) 
becomes  operational,  this  problem  will  be  particularly  impor¬ 
tant  to  solve. 

G.  Internet  Services 

It  is  by  no  means  clear  what  set  of  services  should  be  »t.o- 
dardized  and  available  from,  at  least,  all  public  data  networks. 
The  current  CCITT  recommendations  provide  for  ^  utual  cir¬ 
cuit  service  and  terminal  access  service  on  all  public  packet¬ 
switching  networks. 

Although  the  recommendations  (X.3,  X.2S)  provide  for /rag- 
mentation  of  packets  being  delivered  to  a  subscriber  on  a  vir¬ 
tual  circuit,  the  current  X.7S  gateway  draft  recommendation 
uses  an  agreed  maximum  packet  size  of  128  octets  of  data,  not 
including  the  header.  This  agreement  avoids  for  the  moment 
the  need  to  fragment  packets  crossing  a  network  boundary,  as 
long  as  all  subscribers  recognize  that  the  maximum  length  in¬ 
ternetwork  packet  allowed  is  128  octets.  Bilateral  exceptions 
to  this  rule  may  develop  but  neither  a  fixed  size  nor  a  collec¬ 
tion  of  special  cases  represent  a  very  general  solution  to  this 
problem. 

It  has  been  argued  (25)  that  a  general  scheme  for  dealing 
with  fragmentation  is  desirable  so  that  new  network  technol¬ 
ogies  supporting  larger  packet  sizes  can  be  easily  integrated 
into  the  multinetwork  environment. 

Apart  from  fragmentation,  there  are  a  set  of  special  services 
such  as  multidestination  addressing  and  broadcasting  which 
could  be  used  to  good  advantage  to  support  multinetwork  ap¬ 
plications  such  as  teleconferencing,  electronic  mail  distribution, 
distributed  file  systems,  and  real-time  data  collection.  Other 
services  such  as  low  delay,  high  reliability,  high  bandwidth, 
and  high  priority  are  also  candidates  for  standardization  at  the 
internet  level 

As  in  the  case  of  access  control,  selection  of  such  services 
might  constrain  the  choice  of  packet  routing  to  networks 
capable  of  supporting  the  desired  services.  Once  again,  very 
little  experience  with  standard  internet  services  has  been  ac¬ 
cumulated  so  this  subject  is  still  a  topic  for  research.  For  the 
most  part,  terminal-to-host  services  have  been  successfully  of¬ 
fered  across  network  boundaries  using  nearly  all  of  the  net¬ 
work  interconnection  methods  described  in  this  paper.  It 
remains  to  be  seen  whether  more  complex  applications  can  be 
equally  well  supported. 

Vll.  X.25/X.75-THE  CCITT  STRATEGY  FOR 
Network  Interconnection 

The  common  network  access  interface  concen-;  is  favored  by 
CCITT  for  network  interconnection.  In  the  CCITT  model  of 
packet  networking,  all  networks  offer  the  same  interface  to 
packet-mode  subscribers  and  this  is  called  X.25.  X.25  is  a  vir¬ 
tual  circuit  interface  protocol.  However,  gateways  between 
networks  employ  an  interface  protocol  called  X.7S  (33), 
which  is  much  like  X.25  but  accommodates  special  network/ 
network  information  exchange,  such  as  routing  information, 
accounting  information,  and  so  on. 

Fig  10(a)  illustrates  the  basic  network  interconnection 
strategy  proposed  by  CCITT.  To  appreciate  the  difference 
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between  this  strategy  and  the  “common  subnetwork"  strategy, 
it  is  necessary  to  have  some  understanding  of  the  X.2S  packet 
network  interface.  X.2S  provides  a  virtual  circuit  interface  for 
the  setup,  use,  and  termination  of  virtual  circuits  between 
subscribers  of  the  networks.  X.25  provides  for  flow  control  of 
packets  per  virtual  circuit  flowing  into  or  out  of  the  network. 
Subscribers  may  set  up  switched  virtual  circuits  by  sending 
“call  request"  packets  into  the  network  and  receiving  “call 
confirmation"  packets  in  return.  The  standard  also  provides 
for  permanent  virtual  circuits. 

The  public  networks  plan  to  employ  X2S  interfaces;  it  can 
therefore  be  assumed  that  source  and  destination  hosts  in  dif¬ 
ferent  networks  will  essentially  want  to  exchange  “call  request” 
and  “call  accepted"  packets  through  the  mediation  of  one  or 
more  gateways.  This  strategy  could  result  in  a  series  of  virtual 
circuits  chaining  source  host  to  gateway,  gateway  to  gateway, 
and  pteway  to  destination  host;  alternately  an  end-to-end 
virtual  circuit  could  be  set  up  from  source  host  to  destination 
host,  with  the  gateways  acting  as  relays  without  any  special 
knowledge  of  the  virtual  circuits  passing  across  the  network 
boundary. 

The  principle  difference  between  the  X.2S  interface  and 
X.7S  interface  is  that  virtual  circuit  setup  and  clearing  packets 
are  passed  transparently  by  the  X.7S  gateway  to  the  next  gate¬ 
way  or  destination.  For  reasons  which  are  described  below,  it 
is  necessary  to  maintain  the  sequence  of  packets  belonging  to 
a  given  X.25  virtual  circuit  as  they  pass  through  a  gateway  and 
enter  the  next  network.  Therefore,  a  virtual  circuit  is  in  fact 
created  between  the  source  host  and  intermediate  pteway  and 
between  gateways.  The  X7S  gateway  does  not  spontaneously 
generate  any  “call  acceptance"  packets  in  response  to  “call 
request"  packets,  but  it  does  participate  in  the  sequencing  and 
flew  control  of  packets  on  each  virtual  circuit  passing  through. 
Other  differences  between  the  X,25  and  X75  interface  have  to 
do  with  the  nature  of  the  internetwork  accounting  or  rc  ‘':ing 
information  which  might  be  exchanged  over  X.7S  which  would 
not  be  appropriate  for  a  subscriber  to  exchange  with  the  net¬ 
work  over  the  X.  25  interface. 

The  design  of  the  X75  type  of  gateway  depends  in  principle 
upon  all  networks’  use  of  the  X.25  subscriber  interface.  Some 
networks,  like  the  ETHERNET,  cannot  implement  it  without 
extensive  modification,  because  there  are  no  packet  switches 
in  the  network  to  support  the  required  packet  reordering  at 
the  destination.  The  alternative  is  to  insist  that  all  internet 
applications  rely  on  a  sequenced  data  protocol  built  into  the 
hosts  or  front-ends.  For  some  services,  such  as  packet  speech, 
the  potential  overhead  of  resequencing  packets  before  deliveiy 
to  the  destination  may  prevent  the  service  from  being  viable. 
This  problem  could  be  amplified  if  packets  are  constrained  to 
remain  in  sequence  as  they  pass  the  X.75  boundary. 

Fig.  10(b)  and  (c)  shows  variants  of  the  CCITT  intercon¬ 
nection  strategy.  In  Fig.  10(b),  we  see  an  example  in  which 
only  X.25  is  used  both  u  a  network  access  method  and  as  a 
means  of  passing  traffic  across  network  boundaries.  A  single 
subscriber  or  a  pair  of  subscribers  to  two  nets  could  interface 
to  their  networks  vis  X.  2 5  and  to  each  other  by  means  of 
some  agreed  and  possibly  private  protocol 

Virtual  circuits  would  be  explicitly  set  up  from  source  host 
to  gateway,  gateway  to  gateway,  and  gateway  to  destination 
host.  The  “internet"  addresses  of  the  source  and  destinalion 
hosts  could  be  carried  in  the  so-called  “Call  User  Data  Field” 
of  an  X25  Call  Request  packet.  This  leaves  the  packet  address 
field  free  to  identify  intermediite  destinations  (e^.,  gateways). 
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but  preserves  an  ultimate  internetwork  source/destination  ad¬ 
dress  which  the  gateway  can  use  to  select  the  destination  to 
which  the  next  intermediate  virtual  circuit  is  to  be  set  up. 

An  alternative  to  this  is  shown  in  Fig.  l(Kc)  in  which  the 
subnets  A  and  B  use  nonstandard  virtual  circuit  interfaces,  but 
agree  to  build  gateway  software  employing  X.75  signaling  pro¬ 
cedures  across  the  gateway  interface.  This  solution  is  substan¬ 
tially  the  same  as  that  shown  in  Fig.  10(b),  except  there  is 
now  additional  translation  software  in  each  gateway  half  to 
make  each  virtual  circuit  network-access  protocol  compatible 
with  X.7S  procedures. 

There  are  some  specific  problems  with  the  X.2S/X.75  gate¬ 
way  strategy,  which  do  not  necessarily  apply  to  other  virtual 
call  gateways  (63).  The  basic  X.2S  interface  provides  for  the 
sequence  numbering  of  subscriber  packets  mod.  8  or,  option¬ 
ally,  mod.  128.  Since  X.25  is  an  interface  specifleation,  this 
numbering  can  only  be  relied  upon  to  have  local  significance 
(i.e.,  host-to-packet  switch).  Some  X.2S  implementations  use 
these  host-assigned  sequence  numbers  on  an  end-to-end  basis. 
Others  generate  internal,  net  work -supplied  numbers  to  allow 
for  repacking  of  subscriber  packets  into  larger  or  smaller  units 
for  transport  to  the  destination.  If  packet  sequence  numbers 
assigned  by  the  rource  host  were  carried  transparently  to  the 
destination  without  change,  it  might  be  possible  to  allow 
packets  to  flow  out-of-order  across  the  X.7S  boundary  to  a 
gateway  and  thence  into  the  next  network.  If  the  packet  se¬ 
quence  numbers  were  still  intact,  they  could  be  carried  out-of- 
order  to  the  next  destination  which  might  either  be  a  gateway 
or  an  X.2Shost.  In  the  latter  case,  the  original  packet-sequence 
numbers  could  be  used  to  resequence  the  packets  before  de¬ 
livery.  If  the  packets  were  being  debvered  to  an  intermediate 
gateway,  they  would  not  have  to  be  sequenced  there.  How¬ 
ever,  the  X.25  interface  specification  does  not  undertake  to 
carry  the  host-supplied  sequence  numbe.rs  to  the  destination 
gateway  or  host  in  a  transparent  fashion,  primarily  so  that  the 
subnetwork  can  deal  more  freely  with  the  physical  packaging 
of  the  packet  stream.  For  example,  a  source  may  supply 
packets  of  length  1 28  bytes  while  a  destination  may  prefer  to 
receive  packets  no  longer  than  64  bytes.  To  allow  for  such 
variations,  the  network  must  be  free  to  renumber  packets  for 
delivery.  These  considerations  have  two  consequences. 

1)  X.25  packet  sequence  numbers  cannot  be  reUed  on  for 
end-to-end  signaling,  though  they  could  be  so  used  if  requisite 
information  is  known  about  the  intermediate  transit  networks. 

2)  Packets  must  be  delivered  in  sequence  when  passing  to  or 
from  gateways  and  hosts  on  X.25  networks. 

The  second  conclusion  may  be  modified  slightly.  It  is  at 
least  essential  that  packets  be  delivered  in  relative  sequence  on 
each  virtual  circuit.  By  maintaining  independent  sequence 
numbering  on  each  virtual  circuit,  it  is  possible  for  hosts  and 
gateways  to  refuse  traffic  on  one  virtual  circuit  while  accepting 
traffic  on  another.  There  are  two  penalties  for  this.  Fiik!  a 
gateway  must  keep  track  of  which  virtual  circuits  are  passing 
through  it.  Second,  dynamic  alternate  routing  of  packets  be¬ 
longing  to  the  same  virtual  circuit  through  aitefnatc  gateways 
is  not  possible  without  resetting  or  clearing  the  virtual  circuit. 
This  last  point  is  simply  the  consequence  of  not  defining  an 
end-to-end  sequence  numbering  scheme,  but  instead  relying  on 
sequencing  of  the  packets  of  a  virtual  circuit  on  entry  to  and 
exit  from  each  intermediate  network. 

Some  networks  implement  X.2S  level  acknowledgments 
(i.e..  level  3)  that  have  an  end-to-end  significance,  but  others 
make  this  purely  a  host-to-packet  switch  matter.  As  a  cense- 
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quence,  it  is  not  possible  to  rely  on  X.2S  packet  acknowledg¬ 
ments  to  determine  which,  if  any,  packets  were  not  delivered 
as  a  result  of  the  resetting  or  clearing  of  a  virtual  circuit.  Fur¬ 
thermore.  even  if  a  subnet  wc;e  to  off.v  an  end-to-end  ac¬ 
knowledgment  between  a  source  host  and  an  X.7S  gateway,  this 
could  not  be  assumed  to  guarantee  that  the  acknowledged 
packet  was  delivered  to  the  ultimate  X. 2 5  destination  in  another 
network. 

X.7S  is  an  interface  intended  for  use  between  public  net¬ 
works.  Thus,  it  is  not  likely  to  be  used  or  even  aUowed  as  an 
interface  between  public  networks  and  private  networks.  For 
the  case  illustrated  in  Fig.  14,  X.25  interfaces  could  be  pro¬ 
vided  between  public  and  private  networks  (or  other  special 
interfaces)  and  X.75  interfaces  between  public  networks.  Con¬ 
sequently.  gateways  between  public  and  private  networks  are 
likely  to  appear  to  be  ordinary  host  computers  in  the  view  of 
the  public  networks. 

The  use  of  X.2S  for  private/public  network  interfaces  and 
X75  for  public/pubiic  network  interfaces  leads  to  the  situa¬ 
tion  shown  in  Fig.  14  in  which  an  internetwork  virtual  circuit 
would  have  to  be  made  up  of  several  concatenated  parts  such 
as  virtual  circuits  1-2-3-4  (see  also  (52,  Fig,  3.41).  Even  if 
X.25  implementations  uniformly  permitted  an  end-to-end 
interpretation  of  packet  sequence  numben  and  acknowledg¬ 
ments,  there  would  still  be  separate  virtual  circuits  required 
between  the  source  or  destination  hosts  and  the  gateways  into 
the  public  networks.  However,  the  concatenation  of  virtual 
circuits  does  not  yield  a  virtual  circuit.  For  instance,  a  gate¬ 
way  between  the  public  and  private  net  could  acknowledge  a 
packet  but  fail  to  get  it  delivered,  in  which  case  the  subscriber 
will  have  been  misinformed  as  to  the  delivery  of  the  packet. 
This  situation  foises  the  end  subscriben  of  private  networks  to 
implement  end-to-end  procedures  on  top  of  any  concatenated 
vuTual  circuits  provided  by  the  public  networks. 

VllL  Practical  Network  CoNNEcnoH.s  and 
Experiments  in  Progress 

A  number  of  networks  have  been  connected  successfully 
over  the  last  few  years.  Most  of  these  connections  have  been 
made  in  an  ad  hoc  manner,  using  one  of  the  following  tech¬ 
niques. 

1)  One  network  is  a  star  network  with  remote  RJE  and  in¬ 
teractive  stations,  .'he  other  is  a  star  or  distributed  network 


with  clearly  defined  protocols.  A  device  on  the  star  network 
provides  exactly  the  functions  required  by  its  own  network  on 
one  side,  and  those  of  the  other  network  on  the  other  tide. 

2)  Formal  gateways  are  provided  between  the  twonetworiu, 
and  protocol  mapping  occurs  in  the  gateway. 

3)  A  computer  is  a  host  on  two  networks.  It  is  arranged 
that  services  are  provided  by  accepting  input  from  one  net¬ 
work  and  putting  it  out  on  another,  possibly  after  substantial 
processing. 

4)  Forma)  gateways  are  provided  between  the  two  networks. 
Sufficient  agreement  is  obtained  that  end-to-end  protocols 
(even  high  level  ones)  are  common  in  the  two  networks.  In 
this  case,  less  activity  is  required  in  the  gateway. 

In  the  first  method,  a  form  of  front-end  computer  is  used. 
It  has  been  adopted  in  the  large  airline  and  banking  networks 
SITA  (13)  and  SWIFT  [14].  In  each  case  the  standards  for 
the  networks  have  been  defined  rigidly.  SWIFT  has  even  certi¬ 
fied  officially  the  devices  of  three  manufacturers  to  provide 
interfaces  to  its  network.  The  other  side  of  the  device  is  then 
programmed  to  meet  the  requirements  of  the  star  system  being 
attached.  In  the  two  cases  cited,  only  a  simple  message  level 
of  interface  needed  to  be  defined. 

Other  examples  of  the  same  technique  are  the  connection  of 
the  Rutherford  Laboratory  (RL)  star  system  |S3]  and  the 
Livermore  (TTRNET  to  ARPANET.  In  these  examples,  more 
serious  protocol  mapping  wu  required.  ARPANET  has  a  well- 
defined  set  of  HOST-IMP,  HOST-HOST,  Virtual  Terminal,  and 
File  Transfer  protocols.  All  these  had  to  be  mapped  into  the 
appropriate  procedures  for  the  other  network. 

The  second  method  hu  been  applied  only  experimentally. 
The  UCL  interface  between  ARPANET  and  the  UK  Post  Office 
Experimental  Packet  Switched  Service  (EPSS,  [55])  and  the 
National  Physical  Laboratory  interface  between  EPSS  and  the 
European  Informatics  Network  (EIN,  [56])  are  examples  of 
this  technique;  a  demonstration  hu  even  been  made  of  BIN- 
EPSS-ARPANET  with  no  extra  problems  encountered  from 
the  three  networks  being  concatenated.  Technically  there  is 
almost  no  difference  between  the  first  two  methods.  The  sec¬ 
ond  looks  at  first  sight  somewhat  more  general  than  the  first, 
but  almost  the  ume  problems  have  to  be  overcome.  The  diffi¬ 
culties  come  from  the  fundamental  differences  in  the  design 
choices  made  in  the  protocols  of  the  different  networks;  these 
differences  axe  in  general  difficult,  and  even  sometimu  impos¬ 
sible,  to  resolve  completely.  In  the  first  method,  they  can 
sometimes  be  resolved  using  a  specific  facility  in  the  stv  net¬ 
work;  in  the  second,  where  two  distributed  networks  are  in¬ 
volved,  this  recourse  may  no  longer  be  available. 

One  example  of  the  problem  occurs  in  the  connection  of 
EPSS  and  ARPANET.  ARPANET  can  forwvd  any  number 
of  characten  at  a  time,  and  often  uses  full  duplex  remote  echo¬ 
ing.  EPSS  works  m  a  half- duplex  mode,  forwarding  only  com¬ 
plete  records.  A  special  'Transmit  Now"  hu  to  be  input  by 
the  user,  and  interpreted  by  the  gateway,  to  ensure  that  partial 
records  are  forwuded.  Another  example,  from  the  ume  appli¬ 
cation,  occurs  in  File  Transfer.  ARPANET  auumes  i;<n  inter¬ 
active  process  is  bve  throughout  the  Tile  transfer;  all  comple¬ 
tion  codes  a^e  passed  over  this  bve  channel.  The  RL  network 
(and  EPSS)  assume  that  file  transfer  is  a  batch  process;  they 
return  network  completion  codes  at  a  later  tune,  and  may 
delay  acting  on  the  commands.  WUh  the  ARPANET-RL  link 
[53],  the  file  transfer  job  had  to  be  given  a  very  high  priority, 
so  that  the  completion  code  usually  arrived  before  a  timeout 
occurred,  because  of  the  nature  of  the  way  the  computer  wu 
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used  for  Urge  real-time  jobs,  this  did  not  always  ensure  that 
the  job  was  run  in  a  reasonable  time. 

There  are  several  examples  of  the  third  technique.  A  DEC 
PDF  10  machine  used  on  the  Stanford  University  SUMEX 
project  is  a  host  both  on  ARPANET  and  on  TYMNET;  several 
machines  at  Bolt,  Beranek  and  Newman  are  both  on  ARPANET 
and  TELENET.  Because  the  TENEX  operating  system  has 
good  facilities  for  linking  between  programs,  it  would  be  pos¬ 
sible  for  interactive  streams  to  come  in  one  network  and  go 
out  on  another.  File  transfer  problems  would  be  simple  in  this 
configuration,  because  the  hosts  obey  all  the  conventions,  in 
any  case,  of  each  network.  Of  course,  this  mode  of  operation 
may  require  that  files  in  transit  between  networks  may  have  to 
be  stored  temporarOy  in  their  entirety  in  the  host  serving  as 
the  gateway  between  the  networks. 

The  fouith  technique  is  newer,  and  has  many  variations.  As 
a  result  of  agreement  on  the  X25,  and  partial  agreement  on 
the  X.7S,  protocols,  PTT  networks  are  able  to  interconnect  in 
a  reasonably  straightforward  manner.  The  connections  between 
DATA? AC  and  both  TELENET  and  TYMNET  have  been  done 
in  this  way.  In  each  case,  there  has  not  been  any  agreement  on 
higher  level  protocols,  so  the  problems  of  host-host  communi¬ 
cation  across  concatenated  networks  is  not  resolved  by  these 
linkups  of  the  subnets. 

The  ARPA-sponsored  INTERNET  project  has  tried  to  stan¬ 
dardize  to  a  higher  level.  A  host-host  protocol  has  been  defined 
(TCP,  (25) ),  and  is  being  implemented  on  a  number  of  differ¬ 
ent  networks  including  Packet  Radio  (20),  (21  ].  ETHERNET 
(18),  LCSNET  (64)  and  the  SATNET  (22).  in  addition  to 
ARPANET.  This  protocol  is  defined  for  use  across  networks; 
thus  each  packet  includes  an  "Internet  Header"  which  is  kept 
invariant  as  the  packet  crosses  the  different  networks.  One 
aspect  of  the  INTERNET  program  is  to  develop  gateways 
which  can  interpret  this  header  appropriately. 

By  late  1976,  the  ARPA  project  had  connected  together  the 
Packet  Radio  Network,  the  ARPANET,  and  the  Atlantic  Packet 
Satellite  Network  using  two  gateways  between  the  Packet  Radio 
Network  and  the  ARPANET  and  three  gateways  between  the 
ARPANET  and  Packet  Satellite  Network.  It  is  routirsely  pos¬ 
sible  to  access  ARPANET  computing  resources  via  either  of 
the  other  nets  and  to  anifkially  route  traffic  through  multiple 
nets  to  test  the  impact  on  performance.  In  one  such  test,  a 
user  in  a  mobile  van  in  the  San  FranoKO  area  accessed  a  DEC 
PDP-10  TENEX  system  at  the  University  of  Southern  Califor¬ 
nia's  Information  Sciences  Institute  over  the  following  path: 

1)  from  van  to  the  Tint  gateway  into  ARPANET  via  the 
Packet  Radio  Network; 

2)  across  the  ARPANET  to  a  second  gateway  in  London, 
using  a  uiellite  link  internal  to  the  ARPANET; 

3)  across  the  Atlantic  Satellite  Network  to  a  third  gateway 
in  Boston ; 

4)  across  the  ARPANET  again  to  USC-IS!. 

The  user  and  server  were  400  geographical  miles  apart,  but  the 
communication  path  was  SOOOO  miles  long  and  passed  through 
three  gateways  and  four  networks.  Except  for  a  slightly  in¬ 
creased  round-trip  delay  time,  service  was  equivalent  to  aduect 
path  through  the  ARPANET,  Since  the  Packet  Radio  Network 
is  potentially  lossy,  can  duplicate  packets,  and  can  deliver  pack¬ 
ets  out  of  order,  the  end/end  TCP  protocol  was  used  to  exer¬ 
cise  flow  and  error  control  on  an  end-to-end  basis.  The  avail¬ 
ability  of  a  common  set  of  host-level  protocols  substantially 
aided  the  ease  with  which  this  test  could  be  conducted. 
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The  ARPA  project  also  has  high-level  standard  protocols  al¬ 
ready  in  existence  to  support  file  transfer  and  virtual  terminals 
(the  FTP  and  TELNET  protocols  (401 ),  and  these  are  being 
retrofitted  above  the  internet  TCP  protocol  to  provide  a  stan¬ 
dard  high-level  internetwork  protocol  hierarchy. 

IX.  Regulatory  Issues 

The  regulatory  issues  in  the  interconnection  of  packet  net¬ 
works  takes  a  different  form  in  North  America  than  elsewhere. 
It  is  hard  in  a  paper  of  this  type  to  more  than  touch  on  some 
of  the  problems  involved.  The  discussion  here  is  simplistic  in 
the  extreme,  and  no  attempt  is  made  to  put  the  issues  in  the 
legalistic  language  they  really  require. 

In  almost  all  countries  the  provision  of  long  distance  com¬ 
munication  transmission  and  switching  is  provided  by  a  regu¬ 
lated  carrier.  In  most  countries  outside  North  America,  this 
carrier  is  a  single  national  entity- ca.Ued  the  "PTT*.  In  some 
countries  (e4.,  Italy)  there  are  different  carriers  for  different 
services- e4.,  telegraph,  telephone,  intercity,  international 
telephone,  etc.  In  North  America  there  are  many  carriers. 
Usually  only  one  in  each  geographical  area  has  a  monopoly  on 
public  switched  voice  traffic.  Also  the  so-called  "Record  (Car¬ 
riers”  have  some  sort  of  monopoly  on  "record  traffic,"  which 
is  message  traffic.  In  a  "Value  Added  Network"  (VAN),  the 
operators  rent  transmission  equipment  from  the  carriers,  and 
then  add  their  own  switching  equipment.  These  VAN's  are 
themselves  regulated  in  what  they  may  do,  what  traffic  they 
may  carry,  and  what  rates  they  may  charge.  Between  North 
America  and  Europe,  specific  "International  Record  Carriers" 
(IRC)  have  monopoly  rights  on  data  and  message  transmission 
-in  collaboration  with  the  appropriate  European  PTT's.  The 
regulations  take  into  account  who  owns  the  hosts  and  termi¬ 
nals,  who  owns  the  switches,  who  rents  the  transmission  lines, 
what  types  of  traffic  is  carried,  what  is  the  geographic  extent 
of  the  network,  and  what  is  the  technology  of  long  distance 
transmission. 

In  Fig.  IS,  a  single  network  N  is  sketched.  It  consuts  of 
switches  S  and  transmission  lines  L ;  these  together  are  called 
the  data  network,  DN.  It  consists  also  of  terminals  T  and 
hosts  H,  the  exact  difference  between  a  terminal  and  a  host  is 
not  very  clear;  we  believe  it  is  assumed  that  terminals  mainly 
enter  and  retrieve  data  without  processing;  while  a  host  trans¬ 
forms  the  information  by  processing.  This  definition  probably 
docs  not  meet  the  picture  of  modern  "intelligent  terminals." 
but  it  is  always  hard  for  the  regulations  to  keep  up  with  the 
technology.  If  the  total  network  is  all  localized  in  one  site,  so 
that  no  communication  lines  crott  public  rights  of  way. 
then  it  can  usually  be  considered  from  a  regulatory  viewpoint, 
u  a  single  hos:t  in  more  complex  network  connections.  The 
hosts  and  the  terminals  can  be  connected  to  the  switches,  and 
the  switches  to  each  other,  either  by  leased  lines,  or  by  the 
Public  Switched  Telephone  Network;  the  first  type  of  connec- 
ticn  is  exiled  s  Ittstd  connection,  the  second  switched.  In  the 
subsequent  discusuon  of  this  seriion,  the  term  "host"  will  in¬ 
clude  localued  networks.  In  general  we  will  assume  the  con¬ 
nections  between  the  switches  are  via  leased  tines,  if  that  u  not 
the  case,  the  regulations  are  much  eased  in  genenl  (though  in 
some  countnes,  like  BraxU.  no  data  transmission  is  permitted 
at  all  via  switched  telephone  lines). 

If  all  Che  hosts  and  switches  are  owned  by  one  organ.tation 
F.  which  viso  leases  the  lines,  then  F  is  said  to  own  and  operate 
the  network,  and  it  u  called  a  "Private  Network."  There  are 
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Fig.  IS.  Schematic  of  one  network. 


minimal  restrictions  on  such  networks-tbough  in  West  Ger¬ 
many,  for  example,  higher  tariffs  are  charged  for  the  leased 
lines  if  any  terminals  or  hosts  are  connected  via  the  PSTN.  In 
most  countries  such  a  network  may  not  be  used  for  the  trans¬ 
fer  of  messages  betwe«n  terminals  belonging  to  organizations 
other  than  P. 

If  the  data  network  belonp  to  one  organization,  and  the 
hosts  to  others,  the  data  network  is  a  VAN.  Stringent  regula-  Fig.  17.  Schamatk  of  PTT  modcL 

tions  apply  to  VAN's,  in  most  countries.  With  rare  exceptions, 
in  most  European  countries,  VAN’s  can  be  operated  only  by 
the  PTT’s.  In  the  U.S.,  they  can  be  operated  by  other  organi¬ 
zations,  but  only  if  approved  as  regulated  Value  Added 
Tiers  ( vac's)  by  the  Federal  Communications  Commission 
(FCC).  One  regulation  imposed  by  the  U.S.  is  that  an  organiza¬ 
tion  operating  as  a  VAC  may  not  also  operate  a  host  for  out¬ 
side  sale  of  services.  For  this  reason,  the  companies  TYM- 
SHARE  and  ITT  have  had  to  spin  off  their  VACs  into  separate 
subsidiaries,  TYMNET  and  ITT  Data  Services. 

In  the  past,  a  few  VAN’s  have  been  permitted  to  operate 
internationally  for  specific  interest  groups.  Two  such  VAN's 
are  SITA  1 14] ,  for  the  airlines,  and  SWIFT  ( 14)  for  the  bank¬ 
ing  community.  Here  the  regulations  can  be  stringent.  SWIFT 
has  to  pay  specially  high  tariffs  for  its  leased  lines;  its  license 
to  operate  may  be  revoked  when  the  PTT's  can  offer  a  com-  il,  Multipto  nr  Mtwork  intereowMctioa. 

pvable  international  service. 

As  soon  as  two  networks,  owned  by  different  organizations, 

are  interconnected,  there  are  regulatory  difficulties.  This  situ-  most  countries,  the  line  is  drawn  between  leased  line  and  PSTN 
ation  is  illustrated  schematically  in  Fig.  16.  Even  if  one  net-  connections.  The  former  arc  usually  not  permitted  without 
work  is  an  internal  one,  so  that  it  can  be  treated  as  a  single  change  of  status  of  the  network; the  latter  wem  to  doamgrade 
host,  its  connection  to  other  network  immediately  changes  the  the  connection  to  that  of  a  terminal. 

latter’s  status.  Thus  in  Fig.  16,  the  connection  of  DA^l  toD\2  The  discussion  above  has  treated  the  types  of  connections 
immediately  changes  DN2  to  a  VAN.  In  Europe  it  has  been  which  can  be  made.  In  adJition,  the  PTT's,  and  the  FCXl  in 
decreed  that  such  private  networks  may  not  connect  directly  the  U.S.,  usually  regulate  the  purposes  for  which  the  network 
to  each  other,  but  only  through  a  PTT  network.  Thus  the  can  be  used.  In  particular,  there  is  a  ban  on  such  networks 
most  general  configuration  permitted  by  the  European  PTT's  being  used  for  message  or  voice  transmission  between  organi- 
is  illustrated  in  Fig.  17.  Moreover,  the  PTT’s  have  also  agreed  zations.  How  such  measures  tie  to  be  policed,  gets  us  into 
that  only  the  X2S  interface  will  be  provided  to  custoraen,  another  regulatory  problem.  For  example  the  UK  PO  |S7) 
though  that  interface  was  defined  for  the  configuration  of  Fig.  has  claimed  a  right  to  inspect  the  contents  of  any  data  mesmge 
1 5  rather  than  1 7.  The  different  PTT  networks  will  themselves  sent  across  lines  leased  from  it :  this  right  would  be  at  variance 
connect  to  each  other  by  the  different  interface  X.7S  as  illus-  with  the  privacy  laws  beir4  enacted  in  many  countries  (58], 
trated  in  Fig.  18.  This  does  not  change,  however,  the  inter-  159].  This  subject  is  a  large  one  in  its  own  right,  and  it  U 
face  seen  by  the  private  networks.  Further  work  is  needed  to  clearly  beyond  the  scope  of  this  paper, 
assets  the  suitability  of  X.2S  in  this  role.  Two  other  service  problems  will  arise  in  international  con- 

In  the  U.S.,  the  regulations  are  not  quite  so  stringent.  Coi>-  nections.  First  the  impact  and  form  of  the  privacy  and  trans- 
neclioni  such  at  Fie.  IS  are  permitted  even  where  one  host  national  data  Dow  regulations  in  different  countries  are  differ- 
belongs  to  a  different  organization  than  the  network  operator  cr.t.  Thus  in  the  interconnection  of  international  networks,  a 
P-provided  such  connection  it  only  limited  and  for  the  pur-  particular  set  of  problems  may  ariK,  even  when  the  appropri- 
poses  of  using  the  facilities  of  that  network.  Thu  type  of  re-  ate  regulations  are  obeyed  in  each  network  separately.  Thus 
laxation  is  really  necessary,  because  of  the  difficulty  of  dts-  both  Network  1  in  couniry'  A  and  Network  2  in  country  B 
tinguishmg  between  a  "ho«"  and  a  ’‘terminal**.  In  pracUce,  in  may  obey  their  own  national  regulations.  However  when  the 
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networks  A  ind  B  are  connected.  Network  I’s  practices  may 
break  country  5’s  regulations,  and  yet  be  accessible  from  coun¬ 
try  B.  It  is  this  class  of  problems  which  delayed  seriously  the 
permission  by  the  Swedish  Data  Inspectorate  Board  for  Swedish 
banks  to  connect  their  networks  to  SWIFT. 

Secondly,  some  of  the  functions  of  networks  or  gateways 
legal  in  one  country  may  be  illegal  in  another.  Thus  U.S.  car¬ 
riers  are  not  permitted  to  do  data  processing  in  their  data  net¬ 
works;  no  such  considerations  apply  in  most  European  coun¬ 
tries.  Some  of  the  protocol  translation  activities,  some  of  the 
message  processing  activities,  and  some  of  the  high-level  ser¬ 
vices  (e.g.  the  provision  of  multiaddress  links)  may  well  be 
classed  as  “Data  Processing,”  and  hence  be  illegal  in  the  U.S. 
In  interconnected  networks,  this  raises  the  possibility  that 
functions  can  be  carried  out  outside  the  jurisdiction  of  the 
country  in  which  the  operator  initiating  the  activity  is  sited, 
and  yet  which  is  illegal  in  that  country.  This  subject  is  treated 
rather  fully  elsewhere  [60] .  A  clear  example  of  this  is  the  use 
of  message  services  operated  by  TYMSHARE  and  CCA  on 
TELENET  and  TYMNET.  WhUe  these  services  are  legal  in  the 
U.S.,  their  use  by  UK  persons  connected  to  TYMNET  by  the 
official  International  Packet  Switched  Service  is  clearly  tech¬ 
nically  illegal;  this  use  would  contravene  the  UK  Post  Office 
Monopoly. 

X.  Unresolved  Rf.search  Questions 

There  are  many  unresolved  research  questions;  on  some  of 
them  even  the  present  authors  do  not  agree  with  each  other! 
Primarily  these  questions  have  a  technical,  policy,  administra¬ 
tive,  economic,  regulatory,  or  operational  aspect,  or  a  combi¬ 
nation  of  these. 

One  example  c  f  this  is  the  question  of  the  procedures  to  be 
used  for  internet  routing.  Here  there  are  technical  questions 
on  what  is  feasible  in  view  of  the  technologies  m  "  ui  the  sub¬ 
nets;  there  are  policy  questions  on  when  third  country  routing 
might  be  allowed;  there  are  economic  considerations  on  how 
much  it  would  cost  to  do  the  necessary  protocol  translation  to 
route  through  third  countries,  and  on  what  charges  the  con¬ 
necting  transit  network  might  make;  there  may  be  regulatory 
questions  on  which  classes  of  data  may  flow  through  specific 
countries  (related  to  the  transnational  data  flow  regulations); 
and  there  may  be  operational  questions  on  whether  in  the  event 
of  failure  in  dynamic  rerouting,  reestabUshment  could  take 
place  with  sufficient  rapidity. 

Among  the  outstanding  research  questions  are.  in  alphabetic 
order,  the  following. 

Acceu  Control:  What  are  the  requirements  and  methods  of 
implementation  of  access  control?  How  should  they  affect 
internetwork  routing? 

Addrrmng:  How  should  the  International  Numbering  Plan, 
which  goes  to  the  level  of  known  subscribers  of  public 
networks,  be  extended?  Should  this  extension  be  in  the  num¬ 
bering  plan  itself,  or  should  additional  user  and  network  in- 
formstion  be  supplied?  Should  there  be  local,  or  only  physical, 
addtesiing?  Should  there  be  internetwork  source  routing 
implied  by  the  addressing? 

Broodcmii  Facilities:  What  is  the  role  of  broadcast  communi¬ 
cation  facilities  m  the  provision  of  iniernei  services?  Should 
facilities  using  it  be  offered?  Should  technologies  supporting 
it  use  it.  particularly  at  gatewiys?  What  are  the  impUcat«ons 
on  protocols.  especuUy  with  respect  to  duplicate  and  error 
detection? 

Datagram  versus  Virtual  Call  Facilities:  How  should  data¬ 
gram  and  virtual  call  facilities  be  mterconrs'cted?  How  can 


one  compare  the  relative  performance  and  costs  of  the  imple¬ 
mentations?  What  criteria  should  be  used  in  any  comparison? 
When  might  datagram,  or  alternatively  virtual  calls,  be  desir¬ 
able  or  essential  between  networks? 

Data  Protection:  What  are  the  effects  of  end-to-end  data 
encryption  on  protocol  translation? 

Flow  and  Congestion  Control:  To  what  extent  should  one 
adopt  congestion  and  flow  control  between  gateways  and  their 
feeding  networks,  between  gateways  directly,  or  between  gate¬ 
ways  and  the  source?  What  are  the  relative  effects  of  just  dis¬ 
carding  packets  in  gateways,  and  relying  on  the  end-to-end 
protocol  to  detect  and  compensate  for  this?  How  is  charging 
for  discarded  packets  arranged? 

High  Level  Protocols:  There  are  still  many  questions  on 
what  should  be  st.nndardized,  and  how  rigid  the  standards 
should  be.  To  what  extent  should  the  individual  networks 
support  common  standards,  and  to  what  extent  should  proto¬ 
col  translation  be  feasible  technically  or  attractive  economi¬ 
cally?  What  are  the  costs  of  maintaining  standards  or  the 
economic  advantages  of  standard  hardware  and  software? 
How  does  the  technology  of  individual  networks  and  the 
proportion  of  internetwork  traffic  affect  the  decisions? 

Internetwork  Diagnosis:  There  are  many  technical  problems 
in  isolating  faults  in  concatenated  networks.  There  are  also 
organizational  and  economic  problems  on  who  should  be 
responsible  for  their  repair,  and  how  costs  for  service  failures 
should  be  allocated. 

Performance:  How  do  choices  of  design  parameters,  and 
network  services,  affect  the  costs  of  the  individual  networks? 
How  do  the  individual  network  performances  and  costs  scale 
to  large  networks?  How  do  the  choices  affect  the  feasibility, 
costs  and  performance  of  the  gateways?  How  do  the  varia¬ 
tions  in  technology  or  choice  of  parameters  affect  the  perfor¬ 
mance  in  interconnected  networks? 

Routing  Policies:  To  what  extent  and  when  should  adaptive 
routing  be  used  between  networks?  How  can  one  recover 
from  the  partitioning  of  a  single  network,  when  there  are  still 
routes  existing  by  going  through  other  networks?  How  should 
administrative  considerations  affect  routing  policies  between 
networks  (pnvacy  regulations,  economic  considerations  of 
internet  payments,  desire  to  provide  for  high  availability,  etc.)? 
When  is  a  hierarchical  organization  more  efficient  that  a  direct 
route  search? 

Services:  What  services  are  needed  on  an  internetwork  level? 
Gearly  interactive  and  bulk  transport  services  must  be  sup¬ 
ported.  What  else  is  needed?  Should  the  internetwork  facilities 
be  able  to  support  voice,  telemetry,  and  teleconferencing? 
What  is  the  cost  of  supporting  these  latter  services,  and  what 
is  their  effect  on  other  facilities? 

X.25  and  X.75  and  Related  Recommendations:  Is  X.25 
suitable  for  transaction  procesung?  Are  the  present  datagram 
proposals  adequate?  How  should  X.25  be  extended  for  inter¬ 
net  addressing?  How  should  X.2S/X.7S  be  modified  to  allow 
the  connection  of  private  to  pubbe  networks,  or  private  net¬ 
works  to  each  other?  Do  the  X3.  X28.  X29  pad  concepts 
extend  well  to  the  internet  environment,  or  should  they  be 
modified? 

XI.  Conclusions 

In  view  of  all  the  unresolved  questions  discussed  in  Section 
X,  most  of  the  cnnclu&ons  which  can  be  drawn  in  this  paper 
must  be  tentative.  From  the  early  part  of  the  paper,  we  have 
shown  that  it  is  essential  that  techniques  be  developed  lor  con- 
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necting  computer  networks.  Moreover,  no  single  set  of  tech¬ 
niques  will  fit  all  applications. 

The  services  which  will  normally  have  lO  be  supported  are 
terminal  access,  bulk  transfer,  remote  job  entry,  and  traiuac- 
tion  processing.  The  quality  and  facilities  of  the  ler.’ices  re¬ 
quired  will  be  very  dependent  on  the  applications. 

The  connections  between  networks  can  be  made  at  the  level 
of  the  packet  switches  or  of  hosts,  and  can  be  on  a  datagram 
or  virtual  caU  basis.  Connection  at  the  packet-switch  level 
requires  broadly  similar  network  access  procedures,  or  com¬ 
plex  protocol  transformation  at  the  gateways  between  the 
networks.  If  the  network  protocols  are  different,  intercon¬ 
nection  can  be  most  easily  achieved  if  done  at  the  host  level. 
The  higher  levels  of  service  can  be  mapped  at  service  centers, 
which  need  not  be  colocated  with  the  pteways-but  very 
different  philosophies  of  network  services  can  be  very  difficult 
to  map.  Alternatively,  subscribers  can  implement  common 
higher  level  protocols  if  these  can  be  agreed  upon. 

The  principal  problems  in  connecting  networks  are  much  the 
ume  as  those  in  the  design  of  the  individual  networks  of  het¬ 
erogeneous  systems-but  the  lack  of  a  single  controlling  au¬ 
thority  can  make  the  multinet  design  problem  more  difficult 
to  solve.  It  is  essential  to  resolve  the  usual  problems  of  flow 
control,  congestion  control,  routing,  addressing,  fault  recovery, 
flexibility,  protocol  standards,  and  economy.  The  public  car¬ 
riers  have  attempted  to  resolve  many  of  these  problems;  par¬ 
ticularly  in  the  areas  of  flexibility,  addressing,  and  economy 
we  feel  their  solutions  are  not  yet  adequate.  At  the  higher 
levels  of  protocol,  much  more  standardization  is  required  be¬ 
fore  we  have  really  utisfactory  long  term  solutions. 

The  advent  of  international  computer  networks,  private  net¬ 
works  which  must  communicate  with  other  private  networks 
(even  if  via  pubhc  ones),  and  the  new  applications  of  computer 
networks,  raise  regulatory  and  legal  iuues  which  are  far  from 
resolution. 

Many  technical  solutions  to  the  problems  of  the  connection 
of  networks  are  discussed  in  this  paper.  Their  applicability  in 
view  of  the  different  technical,  economic,  and  policy  con¬ 
straints  imposed  in  different  countries  must  still  be  assessed. 

References 

ill  L.  G.  Robcrti.  "TeUnai.  rnncipkt  and  praciica,**  in  ^or.  Emr. 
Compitnttg  Conf.  Commufucanom  Networki.  Lo»4on.  Enftand, 
pp  31S-339.  1S75. 

|]|  W.  W.  Cbptham,  F.  E.  Claw.  an4  M.  Narraway. "Daiapac  nai- 
work  ovtrview.”  in  frot.  Thiiil  Imt  Ct  n/  CompaierCommumtca- 
rion.  Toionio.  Canada,  pp.  13S>134,  1S74. 

|3|  J.  Rmda.  "TYMNET  An  altamaiiva  o  parkat  twiuhins  taeh- 
nok>|y,"  in  Eroc.  Imt.  Com/.  Ct  Commtmtemtiom. 

Toronto,  Canada,  pp.  24a>373.  1S74. 

|4|  R.  L.  Milbiain.  “Tha  national  aofiwara  worka  a  diatribittad  pro- 
caaaini  ayitcm."  in  ^rov.  ACM  Aar  Con/..  SaattU.  WA.  1477. 

(SI  A  Danat.  R.  Datpraa.  A  La  Raat,  C.  ficlion.  and  S.  Rittantlialar. 
"Tke  litnck  pabtic  packet  iwtichins  atmoa.  The  TRANSfAC 
network,"  m  Etoc.  Third  Imi  Com/  Compttirr  Comirnttmiemhom, 
Toronto.  Canada,  pp.  2Sl-3*«.  1*74 

(4)  C  W  r.  Dav;«t.  "EURONET  ptoiact."  in  TVoc  Imt  Com/ 

Compwirr  Com>oymu»nom.  Toronto.  Canada,  pp.  23*-23*. 
1*74. 

|7|  R.  Nakamura.  F.  lahnso.  M.  Saaaoka.  and  M.  Nakamara.  "Some 
deaisn  aapam  of  a  pubhc  ewnebad  network."  in  fruc  Third  !mi 
Com/  Computer  Commmmtemnom.  Toronto.  CanoJa.  pp.  317-323. 
1*74. 

|S|  F.  A  Halaal  and  A  J.  Spadafora.  ‘-Siement  lyatam  EDS- A  new 
etored  propram  oontioUed  ewnchrni  lyiiam  (or  telci  and  data 
nelworki."  in  TVoc.  Thmf  Imi  Computer  Com mttntemttome  Com/., 
Toronto.  Canadi.  pp  Sl-Si,  l*7a. 

(*|  T  Lanaon.  "A  public  da;a  network  in  thi  nordic  counirwe."  in 
troc  Tturd  Imt.  Comjmttr  Comimmttcanome  Com/,  Toronto, 
Canada,  pp  344-3<C.  1*74 

il0|  r.  T  Karaiain.  *'Pla£n>4  new  pubhc  data  natworka."  Conapui 


Networks,  voL  I ,  no.  2,  pp.  79-94, 1976. 

111)  P.  T.  F.  Kelly.  "An  overview  of  recent  developments  in  common 
user  data  communications  networks,"  in  Proc.  THirti  Int.  Com- 
puttrCommunicctionsCon/,  Toronto,  Canada,  pp.  5-10,  1976. 

1 12)  — .  "Public  packat  switched  data  networks."  this  issua.  pp. 
IS39-1S49. 

113)  P.  Hirsch,  "SITA  rating  a  packat-switchad  network."  Datarmation, 
vol.  20.  pp.  60-63,  1974. 

1 14)  G.  Lepktvd.  "SWIFT  n«two.rk.’‘  Data  CommyrUeatkttu,  voL  5.  no. 
5,pp.  20-24,  1976. 

1 1 5 1  LG.  Roberts  and  B.  D.  Wenler,  "The  ARPA  network,”  in  Com- 
puter-Communicatioms  Networks,  N.  Abramson  and  F.  Kuo,  Eds. 
Englewood  Cliffs.  NJ:  Prentice-Hall,  1973,  pp.  485-500. 

1 16)  P.  M.  Karp,  "Origin,  development,  and  current  status  of  tha 
ARPANET,"  in  Proc.  COMPCON7S.  San  Frandaco,  CA,  Feb.- 
Mar.  1973,  pp.  49-52. 

1 1 7)  L  Poutin,  ".<*reasniation  and  maior  design  aspects  of  the  CY¬ 
CLADES  computer  natwork."  in  Proc.  Third  Data  Comtmimiea^ 
tioms  Symp.,  Tampa,  FL,  Nov.  1973,  pp.  10-85. 

1 18)  R.  M.  Metcalfe  and  O.  R.  Boggs.  "ETHERNET:  DistribuUd 
packet  switching  for  local  computer  natworka,"  Commun.  ACM, 
vol.  19.  no.  7.  pp.  395-404.  July  1976. 

1 19)  A  S.  Fraaer.  "SPYDER-A  data  communicatioiu  axperimaat," 
Comput  Sci  Tech.  Report,  no.  23,  Ball  Laboratorias,  Dec.  1974. 

1 20 1  R.  E.  Kfihn.  "The  organization  of  computer  reaourcet  in  a  packat 
radio  natwork."  in  Pros.  Nat  Cormputar  Com/.,  AFIPS  Pfsiia.  pp. 
177-186.  May  1975. 

|21)  R.  E.  Kahn,  S.  A.  Gronemayar.  J.  Rurchflal.  and  R.  C.  Kunsal- 
man.  "Advancea  in  packat  radio  lachnoiogy."  this  iatua.  pp. 
1468-1496. 

1 22 1  I.  M.  Jacobs,  R.  Binder,  and  £.  V.  Hoventea.  "Canaral  purpoac 
aatsllite  nctworka."  this  issue,  pp.  1448-1467. 

|23|  D.  Lloyd  and  P.  T.  Kirslein.  "Alternate  approaches  to  the  con¬ 
nection  of  computer  networks,"  in  Proc.  Eur.  Compatimi  Cort/. 
Commwtieatiom  Networks,  London.  England,  ONLINE,  pp.  499- 
504, 1975. 

1 24)  L  Pousin,  "A  proposal  for  hUtrconnecting  packet  awRching  nct¬ 
worka."  IFiP  Working  Croup  6.1,  Genarai  Nou  no.  60,  Mar. 
1974. 

|25|  V.  G.  Cerf  and  R.  E.  Kahn.  "A  protocol  for  packat  network  inter¬ 
connection,"  JEEE  Trams  Commirn.  Tec'^mot.,  vol.  COM -22. 
pp.  637-641.  1974. 

|26)  C.  Sunshine,  "Interconnection  of  computer  networks."  Cempiit 
Arrworki.  voL  I.  1977.  pp.  175-195. 

|27)  CCITT.  "Rveemmendation  X.3:  Iniamational  user  facilities  in 
pubhc  dsis  nstworks,"  PabUe  Data  Networks,  Orampe  Book,  vol. 
viii.2.  Sixth  Plena*y  Aaacmbly,  Int.  Telecommunications  Union, 
Csneva,  Svritterland.  pp.  21-23, 1977. 

1 28 1  CCITT.  "Rccemmandation  X.25:  Intsrfacc  between  data  tami- 
nsl  equipment  (DTE)  and  data  circuit-terminating  equipment 
(DEC)  for  terminals  operating  in  the  packet  mode  on  pubhc  data 
networks,"  PaMe  Data  Networks.  Oramgt  Book.  voL  VIII.2. 
Sixth  Pknary  Aasembiy,  Int.  TaUcommunicatioM  Union,  Geneva, 
SwIticrUnd,  pp.  70-108.  1977. 

1 29 1  CCITT,  "Provisional  racommendations  X.3.  X.29.  JL28  and  )L29 
on  packat-ewitchrd  aitt  trsnsmimion  services."  Int.  Telecem- 
mvnirstioni  Union,  Geneva.  Switierland.  1977. 

|30|  CCITT.  "Racommendstion  X.I31-lni.  numbenng  plan  for  pub- 
bc  data  networks.”  Study  Croup  VII.  Temporary  Document 
76-E.  Int.  Tsiacommunicsttons  Union.  Geneva.  Switserland. 
Ap.TI  25.  197d. 

1 31 1  L  Pousin,  "Vmual  cveui't  vs  datagrams- Tschnical  and  political 
problems,"  in  »oc.  Nat  Compater  Com/.,  AFIPS  Press,  pp.  4g3- 

494.  1976. 

1 32 1  L.  C.  Roberii,  "IntsrnstionsI  cennsclion  of  pubhc  pseksi  net¬ 
works."  in  proc.  Third  Imt  Com/.  Compater  Comumamicaiioms. 
Toronto,  Canada,  pp.  23*-245.  1*76. 

1 33)  CCITT.  "R  acorn  mend  at  ion  X.75-Terminal  and  tranait  call  con¬ 
trol  procedural  and  data  uanifar  ay  stem  on  inicmttional  cvcuht 
between  packat  switched  data  natworka."  Study  Group  VII, 
Temporary  Document  132-E.  int.  Telecommunications  Union. 
Geneva.  Switserland.  Ape.  25.  l*7g. 

1 34 1  D.  J.  larber  and  u  C.  Larson,  "The  Hiucturs  of  s  dietrtbutsd 
compvtiag  lyitsm-The  communicstioa  tysiem,"  in  Prov.  Symp. 
Compater  Commam*cai*omj  Networks  and  T*a//ic,  Polytschnic 
institutsef  Brooklyn,  pp.  21-37.  Apr.  1*72. 

I  35)  r  Barsn.  "Broad  band  mieradiva  communicniien  ■errtces  to  tha 
home  Part  Il-lmpaaac,"  IEEE  Trams  Commamtcaitoms.  p.  l7g. 
Jan  1*75. 

1 36)  R.  I-  Schants  and  R.  Thomaa.  "Operating  lyaiami  for  computer 
netnoiki.”  Comparer.  Jan.  1*71. 

1 37 1  L  Poutm  and  H  Zimmermann.  "A  tutorial  on  protoccdi."  this 
taaut.pp  1 34a -1 370 

131)  i.  L  Mean.  R  L  Kahn.  S  M.  Ommin.  W.  R.  Crowther.  and 
D  C.  Walden.  "The  intedace  mem^r  ptoreaaot  for  the  ARPA 
computer  network.”  in  Proc.  Sprms  Joimt  Compater  Com/.,  vol 
34.  AFIPS  Preaa.pp  551-547,1*70 


3-122 


I- 

/An 


1^- 

Cvj" 


u. 


Ik 


i 


Hf'i 


E  J 


IMPLEMENTATION  GUIDELINES 


1408 


(39 1  S.  Carr.  S.  D.  Crockar  and  V.  G.  Carf.  "Hott-Hoit  oommunka* 
tion  protocol  in  lha  ARPA  network,”  in  Proc.  Spring  Jobtt  Com’ 
purer  Conf,.  voL  36.  Atlantic  City.  NJ:  AFIPS  Praia,  Montvala, 
NJ.  pp.  S89lS98.  1970. 

(40]  E.  Fainter  and  J.  &  Postal  (EJa.),  ARPANET  Protocol  Handbook. 
Natwork  Information  Cantar,  SRI  Intamational,  for  tha  Dafanaa 
Communication  Afancy,  Jan.  1978. 

(41 )  R.  F.  SprouU  and  R.  D.  Cohan.  "High-laval  protocola."  thia  iaaua. 
pp.  1371-1386. 

(43|  S.  D.  Crockar,  J.  F.  Haafnar,  R.  M.  Matcalfa,  and  J.  B.  Poatal. 
“Function-ortentad  protocola  for  tha  ARPA  computer  natwork," 
in  Proe.  Spring  Joint  Computer  Conf.,  «oL  40.  Atlantic  City, 
NJ:  ARPS  Praia,  Montvala,  NJ.  pp.  371-379.  1973. 

(43|  S.  M.  Omatain.  F.  E.  Heart.  W.  R.  Crowthar.  H.  K.  Riaing.  S.  B. 
Ruaaal,  and  A.  Michal,  "Tha  terminal  IMP  for  the  ARPA  com¬ 
puter  natwork.”  In  Proc.  Spring  Joint  Computer  Conf,  vd.  40, 
.Mlantic  City.  NJ:  AFIPS  Pram.  Montvalc.  NJ.  pp.  343-3S4. 
1973. 

•44]  CCITT,  "Racommtmdation  X.31:  General  purpoae  intarfaca  be¬ 
tween  data  tsrminal  aquipment  (DTE)  and  deta-circuit  tarminat- 
taig  aquipmant  (DCE)  for  aynchronous  operation  on  public  data 
natworka,"  PubUc  Date  Neneorke,  Oranga  Book,  voL  VUL3, 
Siath  Plenary  Aaaambly,  Int.  Tatecommunicationa  Union,  Geneva, 
SwKiariand,  pp.  38tS6,  1977. 

(4S|  CCITT,  "Racommandatioa  X.3l-bin:  Uaa  on  public  data  nat¬ 
worka  of  data  terminal  equipment!  (DTE’a)  which  ara  designed 
for  intarfacing  to  V-aariea  modams,"  Public  Data  Networks, 
Orange  Rook,  vol.  *iii.3.  Sixth  Plenary  Aaaambly.  Int.  Telecom- 
municaticna  Union.  Geneva,  Switterland,  pp.  38-96.  1977. 

(46 1  ISO.  ”H«h  level  data  Unk  control  (HDLC),"  DIS  3309. 2  and  DIS 
4335,  Int.  Standards  Org. 

(47|  V.Cerf.A.  McKentie.  R.  Scantlebury.  and  H.  Zimmarmann. "Pro¬ 
posal  for  an  international  end-to-end  protocol,"  Computer  Com 
munication  Reuiew,  ACM  Special  Intereat  Group  on  Data  Com- 
munkxtion,  voL  6,  no.  1,  Jan.  1976.  pp.  63-89. 

(48)  A.  S.  Chandler.  "Network  independent  high  level  protocols,"  in 
Proc.  Cur.  Computing  Conf  Communication  Networks,  London, 
England.  ONLINE,  pp.  913-603,  1979. 

(49 1  — ,  "A  network  independent  file  transfer  protocoL”  EPSS  High 
Laval  Prctocol  Croup,  1977. 

(90 1  R.  E.  Kahn  and  W.  R.  Growths;.  "Flow  control  in  resource  shar¬ 
ing  computer  natworka,"  /£££  Tran*.  Commun.,  vol.  COM-30, 


PROCEEDINGS  OF  THE  IEEE,  VOL.  66.  NO.  11.  NOVEMBER  1978 


pp.  939-946. 1973. 

(91 1  L  Pousin,  "Flow  control  in  data  nctworks-Mathods  and  tools,” 
in  Proc.  Third  Int  Conf.  Computer  Communication,  Toronto, 
Canada,  pp.  467-474.  Aug.  1976. 

(S3 1  C.  V.  Bochmann  and  P.  Goyer,  "Datagrams  u  a  pubUc  packet- 
switched  data  transmission  service,"  Universite  da  MontreaL  De- 
partement  D'Informatique  Report,  Mar.  1977. 

(93)  P.  L.  Higginson.  ‘The  problems  of  linking  sevaral  networks  with  a 
gateway  computer,”  in  Proc.  Eur.  Computing  Conf  Communico’ 
tion  Networks,  London,  England,  ONLINE,  pp.  493-469,  1979. 

( 94 1  J.  Shoch, prfvere  communication. 

(99)  P.  L.  Hig^nson  and  Z.  Z.  Fiachar,  "Experience  with  tha  initial 
EPSS  servka."  in  Proc.  Eur.  Computing  Conf  Communication 
Networks.  London.  England.  ONLINE,  pp.  981-600, 1978. 

(96)  D.  L  A.  Barber,  "A  European  informatics  network:  Achieve- 
manta  and  prospects,"  in  Proc.  Third  Int  Conf  Computer  Com 
munication,  Toronto,  Canada,  pp.  44-90,  1976. 

(97)  &  Crou,  "General  Ikenae  for  messaite  conveying  computers," 
Londott  Gasette,  pp.  7663-7663.  May  38,  1976. 

(98)  J.  Fraese,  "The  Swedish  data  act,"  in  Proc.  Conf  Trartsnational 
Data  Regulation,  Brussels,  Belgium.  ONLINE,  pp.  197-308, 
1978. 

(99)  IL  Turn,  "Implementation  of  privacy  and  security  requirements 
in  transnational  deta  procening  systems,"  in  Proe.  Conf.  Trans- 
national  Date  Regulations,  Brussels,  Belgium.  ONLINE,  pp.  113- 
133,  1978. 

(60)  A.  R.  D.  Norman,  "Project  goldfish,"  in  Proe.  Conf  Trartmational 
Data  Regulations,  Bruaseb,  Belgium,  ONLINE,  pp.  67-94,  1978. 

(61)  E.  Raubold  and  J.  Ha?!«lc.  "A  method  of  deadlock-free  reaourca 
al'ocai.on  and  flow  control  in  packet  networks."  »■  Proc.  Third 
Int  Conf  Computer  Communication.  Toronto.  Canada,  pp.  489- 
487.  Aug.  1976. 

(63)  J.  McQuillan.  “The  evolution  of  message  processing  tachniqum  in 
the  ARPA  network.”  Network  Systems  and  Software.  Infotech 
State  of  the  Art  Report  34.  Infotech  Information  Limited,  Nkh- 
olson  House.  Maidenhead.  Iterkshira,  England,  1979. 

(63)  P.  Curran.  “Design  of  a  gateway  to  interconnect  the  DATAPAC 
and  TRANSPAC  packet  switching  networks,"  Computer  Com 
munication  Networks  Group,  E-Report  E-67.  University  of 
Waterloo.  Cenads.  Sept.  1977  (ISSN  384.9703). 

(64)  D.  D.  Owk.  K.  T.  Pogran,  and  D.  P.  Reed,  "An  introduction  to 
local  area  networks."  this  imus,  pp.  1497-1917. 


5-123 


IMPLEMENTATION  GUIDELINES 


PROTOCOLS  IR  A  CCJHPUTER  IWTERNETWORKIRC  ENVIRONMENT 
Ray  2.  McFarland  Jr. 


Oaitad  Scacaa 
Oapartarnt  of  Dafanat 


ABSTRACT 

This  paper  prasants  a  aodsl  for  protocol 
layering  In  a  computer  Int erne tvor king  environment. 
Four  distinct  protocol  layers  are  Identified;  the 
network  layer,  the  Internet  layer,  the  transport 
layer,  and  the  application  layer.  The  functions  of 
each  are  defined.  Gateway  functions  are  also 
addressed  In  the  dlscueslon  of  the  Istemat  layer. 

A  set  of  protocols  are  defined  for  the  transport 
layer  based  on  cooDunlcetlons  requirements;  a 
reliable  data  protocol,  a  datagram  protocol,  a 
speech  protocol  and  a  real  time  protocol. 
Alternatives  for  standardisation  at  the  network, 
Internet  and  transport  layers  ire  presented.  Some 
Impacts  of  choosing  each  alternative  are  dlscuesed. 


INTRODUCTION 

Computer  networks  are  playing  a  more  Important 
role  every  day  within  the  Department  of  Defense. 
More  and  more  projects  situated  on  different 
networks  are  finding  that  they  have  a  requirement 
to  inxercommunicate.  These  requirements.  In 
addition  to  the  direction  being  taken  by  DoD  to 
have  one  long  haul  coamon  terrier  (that  la, 

AUTODIN  II)  rather  than  many  large  geographically 
dispersed  special  purpose  networks,  are  leading 
to  Che  development  of  computsr  Internetworking 
stratagles. 

In  order  to  eschange  information  In  a 
meaningful  way  through  networks  of  computers, 
there  must  be  an  agreed  upon  protocol,  or  set  of 
protocols.  This  paper  will  present  a  protocol 
layering  model  for  a  computer  Intemetworking 
envlrofSMnc.  Four  distinct  prot  col  layers  will  be 
identified  and  thalr  functions  defined.  The 
functions  of  network  gaCeweys  will  also  be 
addressed  by  the  model. 

Altemacives  for  standardisation  of  three  of 
the  four  leyers  will  be  presented.  Some  of  the 
Impacts  of  the  various  altemacives  will  alee  be 
discus sod. 


A  FROTOCOL  UTERING  MODEL 

One  of  the  definitions  Webster's  New  World 
Dictionary  of  the  American  Language  gives  for 
protocol  la  "the  coda  of  ceremonial  form  end 
courtesies,  of  precedence,  etc.  accepted  as  proper 
and  correct  In  official  dealings,  as  between  heada 
of  states  or  diplomatic  officials"  (1).  In  sveh 
the  sane  way,  a  communication  protocol  la  a 
defined  sat  of  control  procedures  and  formats  for 
the  transmission  of  Information  which  Is  agreed  to 
by  the  owners  of  the  comiunl cat ions  gear  Involved. 
Frotocols  can  be  divided  Into  layers  In  such  a  way 
that  each  layer  Implements  certain  control 
procedures,  which  provide  a  set  of  coununlcatlon 
properties  to  tho  layers  above  It.  Ideally,  the 
higher  layer  protocols  should  be  able  to  taka 
advantage  and  build  on  the  properties  provided  by 
the  layers  beneath  It. 

There  are  four  major  protocol  layers  emerging 
In  the  DoD  computer  Internetworking  environment. 

Vc  call  them  the  network  layer,  the  Internet  layer, 
the  transport  layer  and  the  application  layer. 

These  four  leyers  ara  illustrated  In  Figure  1.  For 
one  example  which  will  briefly  show  how  the  layers 
fit  together,  consider  what  a  message  would  look 
like  on  s  network  with  all  four  layars  present. 

The  first  Item  In  the  meseage  Is  the  network  layer 
header,  which  contains  the  control  Information  for 
the  network  layer.  Next  Is  the  internet  layer 
header,  followed  by  the  transport  layer  header,  an 
eppllcetlon  layer  header  If  the  application  control 
le  not  Implicit  In  the  data,  and  finally  the  data 
Iteelf.  See  Figure  2.  This  section  will  define 
the  control  procedures  of  each  layar. 

The  ARFAnet  will  be  used  In  the  following 
discussion  to  provide  examples.  Further  Infor¬ 
mation  on  the  ARFAnet  Is  given  In  (2)  and  (3). 

The  term  'packet#'  «rlll  be  used  here  to  refer  to 
Integral  tmlts  of  Information  transmitted  on  s 
network.  The  tem  will  be  qualified,  as  In 
'ARFAnet  packets',  when  referring  to  specific 
Implementations  to  avoid  ssibigulty. 

Network  Layar 

The  'lowest*  (furthest  removed  from  tha  user) 
layer  is  the  network  layer.  This  layer  consists  of 
the  control  procedures  required  ts  actually  trans¬ 
mit  packets  physical ly  between  two  subscribers  on 
one  network  (one  or  both  of  which  could  be  a 
gateway  to  another  network),  and  defines  the  inter¬ 
face  to  higher  layer  protocols.  (The  concept  of  a 
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gateway  la  defined  in  the  Internet  Layer  aection 
of  thia  paper.)  For  example,  the  ARPAnet'a  network 
layer  conalata  of  the  IMP-IM?  protocol,  (the  IMP, 
which  atanda  for  Interface  Heaaage  Proceaaor,  ia 
the  ARPAnet  packet  evltch),  and  that  portion  of  the 
Network  Control  Program  which  impleaenta  the  Hoat- 
IMP  protocol,  which  la  uaually  referred  to  aa  the 
aolt,  Beranek  and  Newman  1822  Interface  Specif ica> 
tlon  (3).  Of  neceaalty,  thia  protocol  layer  la 
dependent  on  the  apeclflc  network  technology.  The 
network  protocol  for  an  ARPAnet  type  packet 
avltching  network  will  be  different  than  one  for  a 
ring  network,  a  packet  radio  network,  or  a 
aatelllte  network. 

There  are  two  minimal  control  procedurea 
which  all  network  layera  muat  implement,  addreaairg 
and  routing.  As  noted  in  {6}  and  (5),  theae  are 
not  the  aame  thing.  An  addveaa  definea  where  an 
entity  la  located  and  a  routing  mechaniam  definea 
how  to  get  from  one  addreaa  to  another.  Every 
network  muat  have  the  ability  to  identify  the 
locatlona  of  machines  on  it  (i.e.,  have  an 
addreaalng  achems).  In  addition,  they  muat  have  a 
acheme  for  routing  packeta  between  two  points, 
whether  it  ia  a  static  or  dynamic  scheme,  predeter¬ 
mined  nr  based  on  a  heuristic  algorithm. 

There  are,  of  course,  additional  control 
procedures  which  a  network  layer  may  provide.  One 
of  the  moat  important  from  a  networ*.  health  stand¬ 
point  is  flow  control.  A  properly  Implemer.ted  flow 
control  acheme  allows  the  network  to  protect 
network  resources  from  congestion.  Two  ways  of 
doing  this  are  throttling  network  input  to  a 
certain  maximum  level  and  redirecting  traffic 
around  a  congestion  point  with  a  dynamic  routing 
scheme.  For  example,  the  ARPAnet  allows  only  eight 
ARPAnet  mcaaagea  at  a  time  between  any  two  hoata, 
while  the  dynamic  routing  algorithm  was  intended 
(in  part)  to  handle  traffic  congestion  between  any 
two  adjacent  IMPs. 

This  layer  may  also  provide  error  detection, 
either  on  a  hop  by  hop  baaia  or  on  a  point  of  entry 
to  point  of  exit  basis,  or  aomc  combination  of  the 
two.  A  strictly  hop  by  hop  acenario  is  the 
strategy  typically  used  i.  a  store  and  forward 
network.  When  a  switch  receives  a  packet  it  sends 
an  acknowledgment  to  the  adjacent  sending  ewitch. 
which  is  then  allowed  to  release  its  copy.  One 
diaadvantage  of  thia  scheM  is  that,  if  a  network 
malfunction  orcura,  it  is  ‘>ossible  to  loae 
messages.  A  switch  crashing  after  having  acknowl¬ 
edged  a  message  but  before  sending  it  on  ia  one 
example.  For  a  strictly  point  of  entry  to  point  of 
exit  scenario,  the  destination  awitch  would 
ackncwledgc  the  packet  to  the  source  switch  only 
after  it  had  successfully  passed  it  to  the  intended 
destination.  (This  is  alao  referre-t  to  as  end  to 
end  acknowledgement.)  Thus,  if  the  network 
malfunctions  and  drops  a  packet,  recovery  ia  still 
possible  since  the  source  switch  has  maintained  a 
copy.  An  acknowledgment  from  the  destination 
switch  had  not  yet  been  received  by  the  source 
switch.  The  ARPAnet  actually  uses  a  combination  of 
the  two,  with  inter-LKT  acknowledgments  as  an  ARPA¬ 
net  packet  traverses  the  network  and  s  Ready  For 


Next  Hcasage  (RFNM)  which  is  aent  from  the 
deatlnation  IMP  to  the  source  IMP. 

A  network  may  provide  a  form  of  fragmentation, 
where  meaaagea  delivered  to  thr  network  are  broker, 
down  into  smaller  units  for  trinsmlsslon.  This  la 
another  mechaniam  cotmaonly  used  by  networks  to 
maximize  their  resources.  At  the  destination 
switch,  the  inctvork  is  responsible  for  reassembly 
of  the  fragments  it  haa  created.  The  ARPAnet 
breaks  messages  down  into  packets  for  transmission 
across  the  IMPa  and  reassembles  the  messages  at  the 
destination  IMP. 

A  network  may  also  implement  some  form  of 
precedence  strategy  for  high  priority  packets. 

The  overall  capability  this  layer  provides  is 
the  capability  to  physically  move  packeta  of 
information  between  the  network's  subscrlbars  (or 
gateway/),  without  requiring  the  higher  layera  to 
have  krowledge  of  the  switch  procedures  or  formmta. 

Intemat  Layer 

This  layer  consists  of  the  control  procedurea 
required  to  allow  internet  packets  to  traverse 
multiple  networks  between  any  two  hoata.  This 
protocol  is  usually  implemented  within  hosts  and 
gateways.  The  gateway  attaches  to  tvo  or  more 
networks  and  ia  the  bridge  between  the  networks 
over  which  the  internet  packeta  flow.  The  primary 
function  of  the  gateway  ia  the  passing  of  control 
information  and  data  between  two  networks.  In 
addition,  the  gateway  must  alao  determine  what 
network  layer  control  procedurea  are  to  be  invoked 
for  a  particular  packet.  The  gateway  derives  this 
information  from  the  internet  protocol  header.  It 
should  not  translate  between  the  two  network 
layera.  It  ia  preferably  to  derive  the  control 
information  needed  from  the  internet  header  and 
allow  the  destination  network  to  implement  the 
required  control  within  the  context  of  its  own 
control  conttrocta  rather  than  try  and  match  up  the 
control  conatructa  of  two  network  layer  laple- 
mentationa.  In  general,  the  translation  of  control 
constructs  from  one  network  layer  implementation  to 
another  is  exaaberaome  and  a  one-to-one  mapping  of 
the  control  constructs  of  two  network  protocols  is 
rarely  obtainable.  The  best  chance  to  achieve  such 
a  mapping  la  if  the  two  network  procccols  are 
exactly  the  same,  but  even  then  some  'fudging*  of 
the  protocol  may  be  needed  for  an  Implementation, 
(e.g.,  the  Implementation  and  Interpretation  of  a 
RTKM,  which  ia  and  te  end  intranet,  but  la  no»  end 
to  end  iattmec). 

There  are  three  minimal  control  procedures 
which  the  Internet  laver  must  implement:  address¬ 
ing.  routing  and  fragment  at  ion.  The  internet 
address  must  be  able  to  uniquely  specify  a  location 
on  a  eel  of  networks  and  also  Identify  the  proper 
transport  layer  processing  software  to  which  the 
packets  should  be  sent.  The  usual  mechanism  for 
doing  this  Is  a  hlererchlcal  addressing  scheme, 
such  as  ‘‘network  address  “host  addreas*<  transport 
protocol  processing  module  address*’.  Other 
addressing  schemes  have  also  been  deviped  to  try 
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Asd  rtduct  tha  ovarhaad  of  the  eddreeeing  field  in 
the  header.  Whetevar  acheaa  la  Inpleaaated,  the 
getavay  suat  be  able  to  map  tha  Intamet  addreaa 
to  a  apeclflc  network  eddreaa,  either  tha  intended 
daatlnation  boat  ot  another 

Catavaya  deteraina  tha  routing  at  the  intamet 
layer  when  sore  than  one  getaway  nuat  be  traveraad 
to  reach  tha  daatination  boat.  There  nay  even  be 
two  different  getewaya  between  the  deatination 
network  and  an  Intemadiate  network.  The  gateway 
between  tha  aourca  network  and  the  intaraediete 
network  would  then  be  able  to  chooae  which  gateway 
to  route  tha  peckata  thr'^ugh.  Thia  can  be  even 
sore  algnlficent  when  the  deatination  network  ia  at 
laeac  three  networka  away  from  the  aource  network. 
In  thia  caae,  the  Intamet  routing  could  actually 
datarsine  which  network (a)  tha  packata  are  to  flow 
through.  For  exaaple,  network  A  say  attach  to 
network  B  through  one  gateway,  network  1  attach  to 
network  C  through  one  gateway  and  to  network  D 
through  one  gateway,  network  C  attach  to  network  E 
through  one  gateway,  and  network  D  attach  to  net¬ 
work  E  through  one  gateway  (see  Figure  3).  Two 
alcemece  routea  then  exiat  froa  network  A  to  net- 
\tOTk  E.  One  route  la  A-B-C-E,  the  other  ia  A-B-D- 
E.  The  gateway  can  adjuat  to  gateway  (or  inter- 
■edlate  network)  congaacion  by  dynaalcally  chooaing 
which  gateway  individual  packata  ahould  go  through. 
Thia  ia  analogoue  to  tha  dynamic  routing  algorithm 
in  tha  ABPAnet  mantlonad  earlier.  In  the  aama  way 
that  AKPAnec  peckata  of  e  given  mcaaega  are  not 
conatralned  to  e  apeclflc  aerlea  of  DfFs,  packata 
of  a  given  conneccica  ahould  not  be  conatralned  to 
a  given  aarlaa  of  getewaya.  However,  for  thia  to 
be  poaalblc,  the  packata  of  a  higher  layer  protocol 
connection  auat  not  be  conatralned  to  go  through 
one  apeclflc  gateway  or  aarlaa  of  getewaya  to  reach 
thalr  dcttinetlc4.  (The  concept  of  a  connection  la 
dafinad  in  tha  Tranaport  Layer  aacclon  of  thia 
papar.)  Tha  gateway  ahould  be  oblivloua  to  the 
exiatence  of  connectlona.  An  additional  advantage 
gained  from  thia  approach  la  the  lack  of  a  need  for 
tha  gateway  to  atore  connection  atate  Information, 
allowing  for  e  almplc  and  mora  efflclant  gateway. 
The  proper  place  for  connection  atete  information 
ia  at  the  next  layer,  tha  tranaport  layer. 

Tha  third  minimally  required  control  procedure 
la  fregaenteilon.  (Fregmentetlon  in  e  apeclflc 
gatewey  ia  neceaaery  when  one  of  the  atteched 
networka  hea  a  maximum  packet  alee  which  la  emaller 
than  one  of  the  other  attached  network#'  maxlmltai 
packet  alee.  We  will  aaaume  thia  aa  the  general 
ceae  In  thia  dlacuaaion.)  A  gateway  nuat  have  the 
capability  to  interface  two  a  tworka  which  have 
different  maximum  alee  packet  Icngtha.  To  do  thia, 
the  gatewey  muat  be  able  to  braek  4wn  e  pac'iet 
into  fregmanta,  each  looking  like  an  integral 
packet  to  the  network  with  the  amallar  alte  m^ximuB 
peckat  length.  The  Intamet  protocol  mui.., 
therefora.  provide  the  mesne  for  id^tify.'ng 
fragmenta  and  for  cequcnclng  them  ao  that  they  can 
be  reaaeembled. 

It  la  Important  to  note  that  if  reaaaembly  of 
fragmenta  la  done  at  the  gateway,  then  ell  of  the 
fragmenta  which  amke  up  the  larger  packet  era 


constrained  to  go  through  tha  aaatc  gateway  whan 
leaving  e  network.  For  error  recovery  by  retrana- 
mission,  ths  retrsnsmisslon  of  the  original  psekst 
must  be  constrained  to  the  originally  addressed 
geteway,  which  may  counter  any  dynamic  routing 
algorithm  that  may  exist  at  tha  internet  layer. 
Without  dynamic  routing,  the  geteway  is  a  point  of 
single  failure  for  ell  connections  that  go  through 
it.  With  dynamic  routing  and  the  requirement  for 
reassembly  of  fragments  at  a  gateway,  the  gateway 
may  require  soma  kno\«ladga  of  tha  formats  and  error 
recovery  procedures  of  all  the  transport  layer 
protocols  which  can  pass  through  it.  For  example, 
to  decida  whathar  to  hold  or  discard  a  partial 
packet,  ti'.t  getaway  nay  have  to  know  which  trana¬ 
port  level  protocols  ratransmlt  and  which  do  not. 
This  violates  tha  premiss  that  protocol  layers 
should  be  kept  aeperata  and  distinct,  end  not  rely 
on  the  formats  and  preaduras  of  protocols  that  srs 
at  a  higher  layer.  A  second  disadvantage  to 
dynamic  routing  with  raassambly  at  a  geteway  is 
that  a  gateway 'e  buffers  may  be  tied  up  waiting  for 
a  'lost'  fragment  of  a  packet  whils  ths  retrans¬ 
mitted  psekst  has  elrssdy  passed  through  an 
alternate  gatewey. 

Where  then  should  the  fragments  bs  rssasem- 
blad?  If  the  reader  will  recall,  we  have  bsen 
discussing  ths  functions  of  a  gateway  which  are 
needed  to  process  ths  Intemst  protocol  isysr. 

Tat,  nowhara  was  it  mentioned  that  the  protocol 
layer  is  aithsr  crested  or  terminated  et  the 
gateway.  The  information  has  already  existed  for 
the  getewsy  to  process  it.  All  well  dstlnsd 
protocols  have  (at  least)  two  distinct  ends,  the 
'andc*  for  ths  intamet  layer  era  at  the  source 
and  destlnctlon  hosts.  The  software  which  Imple" 
ments  these  Intsmst  layer  procedures  at  the  hosts 
could  be  loosely  referred  to  as  'half  e  gateway', 
since  it  only  connects  to  one  network.  The  source 
getewsy ‘>helf  is  responsible  for  forming  the 
internet  header,  deriving  the  necsssery  control 
information  from  either  the  host  directly  or  from 
the  transport  layer  header  (s.g.,  precedence, 
sequencing  information,  etc.).  The  dastlnetlon 
getewey-helf  is  responsible  for  reassembling  the 
fragments  end  demultiplexing  the  Intemst  packets 
to  the  proper  transport  protocol  processing 
modules.  Of  course,  some  host  Implcmentstlons  may 
not  have  the  eepcblllty  to  rcessembls  fregments. 

In  this  cese,  the  Inicmct  protocol  muet  allow  for 
the  source  host  to  declare  an  option  of  'do  not 
fragment  this  packet'.  Sateweys  which  have  to 
fragment  theae  type  of  packets  would  either 
discard  them  or  reroute  them  to  another  getewsy. 

In  feet,  this  information  Is  one  of  the  things 
which  cocld  go  into  the  routing  schema  which 
gateways  l^yleser.t  (Including  the  ictewcy-half  at 
the  source). 

For  retrcnamlsslon  efficiency,  one  might  wish 
to  trads  off  some  of  the  flexibility  in  the 
previously  deacrlbed  dyncmlc  routing  scheme  for  c 
simple  error  detection  end  retrencmlaslon 
procedure  between  any  two  gateways.  In  this  case, 
there  Is  still  no  need  to  correlate  two  different 
fragments  ct  an  Intermediate  gateway.  Individual 
network  packctc,  when  retrsnesltted  from  one 
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getcwcy  to  the  other,  would  be  conetralned  to  go 
to  the  getewey  addressed  origloelly.  However,  If 
the  getewey  frcgoents  e  packet;  then  new  Internet 
checksuBs  ere  cooputed  tor  each  fregnent  (%dilch 
becone  individual  packets  for  the  next  network). 
Whet  Is  lost  is  the  ability  to  address  the 
retransnltted  packet  to  an  eltemate  gateway  If 
the  getewey  addressed  originally  is  overloaded  or 
has  crashed.  (A  sore  conplex  procedure  could 
allow  for  both  dynamic  routing  and  getewey  error 
detection  and  retransulesion.  The  conplexity  Is 
in  the  bookkeeping  required  at  the  sending  getaway 
to  allow  It  to  properly  procees  any  returning 
acknowledgMot . ) 

The  Internet  layer  presente  the  capability  to 
■ove  the  packets  over  many  networks  and  hides  the 
necessary  details  of  gateway  functions  frow  the 
higher  layer  protocols.  For  Instance,  the  trans¬ 
port  protocol  layer  need  not  worry  about  getewey 
addreselng  or  network  routing. 

The  functions  of  e  getewey  are  intlMtely 
tied  to  the  Internet  protocol  which  it  Iwpleaents; 
however,  the  gateway  and  the  internet  protocol  are 
not  synonywoua.  A  gateway  aay  have  other  functions 
beyond  the  strict  laplesentetlon  of  the  Internet 
protocol.  These  functions  wust,  however,  seat  the 
requircaent  that  the  gateway  reaaln  slaple, 
efficient  and  easily  aalntelnable.  One  such 
function  haa  already  been  aentloned,  the  aalnte- 
nance  of  network  congestion  Inforaetlon,  which 
contributes  to  the  routing  declalon  at  the  Internet 
layer.  Other  functions  would  be  accounting  end 
reporting  to  eoae  network  control  center (s)  for 
'state  of  the  gateway*  leforaatloo,  such  as  queue 
lengths,  traffic  density,  etc.  A  gateway  could 
also  act  as  am  agent  of  e  network  access  control 
center,  for  network  eecountablllty  and  self 
protection  requlrenente. 

Transport  l^yer 

This  layer  cooslsts  of  the  control  procedures 
necessary' to  deliver  packets  between  two 
application  processes  on  different  host  coaputers, 
whether  the  hosts  are  on  the  sane  or  different 
networks.  Within  networks,  thle  layer  has  been 
coaaonly  referred  to  as  the  Host  to  Host  protocol. 
The  transport  protocol  wodules  Interface  to  Che 
application  layer  software  nodules  (or  ease  host  to 
front  end  protocol  nodule  where  the  transport 
protocol  Is  tenslnated  In  a  front  end).  It  la  at 
the  transport  layer  chat  explicit  connection 
Infomaclon  nakes  sense,  since  connections  ere 
thought  of  as  explicitly  defining  the  tranaalsslon 
path  between  two  (or  wore)  application  layer 
procesacs.  Connection  atste  Infomaclon  and 
connection  nalntenanee  la  wfwr  responsibility  of  the 
transport  layer  protocol. 

One  type  of  transport  layer  protocol  Is  not 
avfflclenc  for  woat  users.  Different  users  have 
different  coweistlcac Ion  requl reaents .  These 
requlrruencs  sre  usually  a  function  of  the  relia¬ 
bility  level  needed,  claellness  of  delivery,  and 
the  need  for  sequenced  delivery  between  two 
application  processes  In  different  hoste.  A 


protocol  which  attespts  to  solve  all  the  naads  of 
all  uaars  will  probably  be  worthlese  to  everyone. 
(It  will  at  the  least  be  grosely  Inefficient, 
sowcthlng  which  cannot  be  tolerated  in  a 
ccHsunlcatlooa  anvironaaot.) 

Four  types  of  protocols  sacc  to  ba  oaaded  at 
this  level ;  a  raliabla  data  protocol,  a  datagraa 
protocol,  epaech  and  a  real  tisM  protocol.  There 
■ay  be  aore,  but  this  paper  will  liait  Ite 
discueelon  to  these  four.  The  following  ditcuselon 
will  net  ettewpt  to  define  all  the  control  proce¬ 
dures  a  particular  transport  protocol  ehould  have, 
but  will  give  a  sufficient  nuabar  to  allow  the 
reader  to  dlatlngulsh  between  the  four  typee. 

The  reliable  data  protocol  is  charecterltad 
by  the  need  for  a  high  level  of  (elleblllty  and 
the  need  for  sequential  delivery  of  the  packets 
tranaalttad  batwaan  two  procesBas. 

The  need  for  sequenced  delivery  leads  to  the 
concept  of  e  coeaunlcetlons  connection  existing 
between  two  proceaeee.  The  defining  cheractar- 
latlca  of  a  connection  are:  (1)  each  end  has  an 
explicit  naae  and  la  asaoclatad  with  a  specific 
proceas;  and  (11)  the  packets  are  saquanced  only 
with  respect  to  the  order  of  trsnealselon  on  their 
connection,  end  Independent  of  the  sequencing  of 
packets  on  other  connections.  The  reliable  date 
protocol  Is  responsible  /or  iaplcaentlng  the 
concept  of  e  connection.  T.\ls  Includes,  but  is 
Bot  Halted  to,  the  opening  end  synchronising  of  a 
connection,  the  aalntananca  of  an  open  connection 
and  the  corresponding  connection  state  Information, 
the  rasynchronlsatlon  of  a  connection  If  and  when 
aeceeeery,  end  the  closing  of  e  connection.  In 
short,  all  the  connection  aanageaent  functions. 

The  reliability  requirement  la  aatlalflad  by 
a  aechanlsa  In  the  reliable  data  protocol  which 
guarantaaa  packet  delivery  at  the  receiver.  To  do 
this,  the  protocol  must  provide  a  sufficiently 
robust  error  detection  acheae  (which  Is  usually 
some  fora  of  cyclic  redundancy  check).  The 
protocol  Bust  also  provide  e  way  to  positively 
•cknowledge  packets  and  Bust  be  persistent  In  the 
retranealeslon  of  packets  until,  positive  acknowl¬ 
edgment  of  en  error  free  delivery  Is  received  or  an 
abort  tlae  out  period  expires.  If  the  abort 
occurs,  the  protocol  must  be  able  to  identify  for 
the  user  which  packets  were  received  end  which 
were  not.  Since  fragmentation,  dynaalc  routing 
etrateglea  and  packets  received  In  error  cen 
reault  In  out  of  order  reception  of  error  free 
packets  and  possibly  duplicate  reception  of  some 
packets,  the  protocol  Bust  coapeneete  by  being 
able  to  detect  duplicate  packets  end  reorder  the 
original  packets  prior  to  delivery  to  the  receiving 
procees.  The  reordering  of  packeta  before  delivery 
also  aide  In  Che  Identification  of  received  peckecs 
for  an  aborted  connect !(». 

One  last  ftstctlonel  requlreaent  for  the 
reliable  data  protocol  la  the  aalntenance  of  e  flow 
control  strategy.  At  this  layer,  the  flow  control 
strategy  Is  aimed  at  the  aanagement  end  protection 
of  Koet  reeourcea,  such  at  the  amount  of  buffers 
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•vallabla  for  rcc«lv«4  ercffic. 

The  second  type  of  transport  protocol  Is  the 
dategrsB  protocol.  This  protocol  Is  charecterlsed 
by  the  lack  of  a  need  for  sequenced  delivery  and 
the  decreased  level  of  relleblllty  required. 

The  datagraa  'service*  basically  hes  a  single 
pecKet  orlencetlon  with  no  relation  axlstlng 
between  packets,  ecnethlng  like  a  telegraa 
service.  Becuase  of  this  characteristic,  there  Is 
leclly  no  need  for  ell  the  overhead  Involved  In 
the  eclntcnancc  of  explicit  connections.  In  feet, 
c  nuaber  of  the  functions  that  a  reliable  data 
protocol  provides,  such  as  flow  control,  are  not 
even  needed.  Establishing  e  connection  for  a 
single  packet  can  be  a  waste  of  trensnlsslon 
resources  and  be  very  Inefficient.  The  datagraa 
protocol  aust  provide  a  way  to  Identify  Individual 
packets,  but  It  does  not  hava  to  sequence  thsa. 

Soae  Individuals  within  the  AVAnet  eoHunlty 
who  have  expressed  e  desire  for  a  datagraa  have 
Indicated  that  thalr  application  layer  protocol 
will  provide  the  degree  of  relleblllty  wanted.  An 
eppllcsclon  layer  protocol  would  slap.ly  retracaalt 
until  soae  fora  of  posltlva  ecknowledgaent  (either 
explicit  or  lapllclt,  such  as  the  results  of  eoac 
Initiated  action  being  returned)  has  been  racalved. 
The  datsgraa  protocol,  then,  aust  laplsaent  soae 
fora  of  error  detection  for  error  free  delivery  of 
packets,  but  It  does  not  have  to  guarantee  the 
arrival  of  the  packets  or  reordar  thaa  or  detect 
duplicates  as  the  reliable  data  protocol  does. 

A  speech  protocol  Is  a  third  type  wf  trans> 
port  protocol.  This  protocol  Is  charecterlsed  by 
tne  need  for  sequenced  delivery  and  the  need  for 
very  tlacly  delivery. 

As  In  the  ease  of  the  reliable  date  protocol, 
the  speech  protocol  requires  a  connectloo  aaaage- 
aent  acchenlsa  to  prsserve  logical  relationships 
saong  the  porkets  through  sequencad  delivery. 

Flow  control  aay  or  aay  eot  be  required,  depending 
on  the  particular  speech  eppllcetloo  and  available 
reeources . 

Individuals  who  are  working  oo  packet Ised 
speech  have  Indicated  that  they  would  prefer  to 
trade  off  e  highly  reliable  protocol  for  one  ^Ich 
Is  very  tlaely  In  Its  delivery  of  packets.  (Note 
that  the  retransaissloo  of  packets  received  In 
error  or  possibly  lost  In  the  network  reduces  the 
tlaellncss  of  their  delivery.)  teorderlng  Is 
required  for  two  reasons,  ordered  delivery  to  the 
sppllcstion  process  end  for  the  detection  of  lets 
arriving  packets,  which  ere  discarded.  Though 
they  require  reordering,  they  dc  not  worry  about 
lost  or  «aulelivered  packets.  Capa  In  the 
reordered  packets  delivered  to  a  speech  algorltba 
do  not  severly  effect  the  quality  of  the  speech, 
unless  the  gap  Is  signif Icwtly  large.  The 
protocol  nuet  thee  provide  for  e  way  of  eequenclng 
the  packets,  reordering  then  and  detect lug 
duplicate  fragnents.  iut  It  does  not  necessarily 
have  to  inplenent  e  positive  ecknowledgaent  scheae 
for  the  purpose  of  retraaaaissloe  of  packets 


which  were  lost  or  recelvad  In  error.  An  error 
detection  scheae  Is  required  no  that  error  packets 
can  be  discarded  at  the  receiver. 

The  fourth  type  of  transport  layer  protocol 
is  for  real  tlae  traffic.  This  Is  the  uost 
difficult  type  of  traffic  to  deal  with,  since  It 
Is  characterized  by  a  need  for  sequenced  delivery, 
and  the  need  for  both  highly  reliable  and  tlacly 
delivery.  The  distinction  mdc  between  speech  and 
real  tlae  traffic  Is  chat  with  spacch,  which  Is 
ultlaatcly  Intended  for  the  hman  ccr,  all  the 
traffic  Is  not  required  for  Intalllgent  processing 
of  the  Infomaclon.  The  ear  Is  an  excellent 
filter  %dilch  cen  Integrate  over  alsslng  traffic, 
cs  long  as  the  gep  Is  not  too  large,  keel  tlae 
traffic  Is  aore  In  the  character  of  data  as 
described  under  the  reliable  data  protocol,  such 
as  tha  rcaotc  control  of  a  sensitive  production 
procesc.  All  of  Che  inforaatlon  Is  required  for 
procecslng.  The  rcqulreaents  for  both  high 
rellsbfllty  and  tiaely  delivery  effects  tha 
technology  choices  of  Che  networks  over  which  the 
Inforaatlon  aust  pass. 

The  types  of  functions  that  this  protocol 
aust  have  :s  a  coablnatlon  of  those  defined  for 
Che  reliable  data  protocol  and  the  speech  protocol. 

Transport  layer  protocols  provide  the  '’trans- 
porcaclor.  aedlua*  to  tha  protocols  at  the 
application  layar.  The  transport  layer  hides  froa 
the  application  layer  the  lapleaentatlon  details 
of  connection  aanageaent  end  flow  control, 
sequencing  end  pseket  errors  (except  for  the  dace- 
graa  protocol).  Fackets  generally  will  be 
delivered  just  as  they  trere  aant,  except  as  noted 
earlier. 

Application  Layar 

This  layer  defines  the  control  procedures 
between  two  application  processes  necessary  to 
ecconpllsh  a  given  task.  For  cxsaiple,  the  control 
procedures  for  an  Infomatlon  retrieval  package 
night  be  wearch,  extract,  sort,  nerge.  etc. 

The  application  layer  protocols  provide  the 
cepeblllcy  for  two  software  processes  to  work 
together.  This  Isyer  slways  exists,  whether 
explicitly  or  inplicitly.  whenever  two  processes 
are  required  to  coenuniesce,  be  they  on  the  sane 
suichine,  the  sane  network,  or  different  nett^rka. 
When  this  layer  Is  explicitly  defined  In  the 
design  stage  of  s  prcject.  It  Increases  ch« 
underacandsbillty  of  the  software  requlrenents  and 
aids  In  the  definition  of  clean  software 
interfacec. 

FROTOCOL  STAiiDAJtDlZATXOM 

lecslllag  our  ioltlcl  definition  of  Che  word 
'protocol'.  It  is  interesting  to  consider  what 
happens  when  two  societies,  which  have  different 
protocols  (or  shall  we  sav  'stendards*  of 
behavior?)  intersec.  The  results  can  be  hunorous. 
confusing,  irritating,  and  souetlMs  even  violent, 
ail  at  the  ssm  tine.  The  effects  can  b*  Che  saoe 


331 


a- 129 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1Q85 


when  different  computer  networke,  which  have 
different  protocols,  want  to  Intercommunicate. 

And  this  leeds  to  the  question  of  etendardlzetlon 
end  the  degrees  of  eCandardlzatlon.  How  much  Is 
sufficient?  Bow  much  Is  too  much?  Whet  are  the 
Issues?  These  questions  ere  questions  which  must 
be  addressed,  and  they  cannot  be  addreseed  In  a 
vecu\m.  Whet  one  orgenlzstlon  does  and  how  they 
do  It  has  an  impact  on  other  orgenizatlons,  and 
vice  Tsraa. 

Stenderdlsctlon  of  the  Network  Layer 

The  definition  of  the  network  leyer  protocol 
Is  primarily  a  function  of  the  technology  of  the 
network  bcceusc  this  Is  the  protocol  responsible 
for  ectually  moving  packets  through  the  network’s 
physclel  ewltches.  The  choice  of  e  specific  tech¬ 
nology  for  networks  Is  usually  driven  by  the  Intra¬ 
network  requirements,  as  It  should  be.  Real  time 
requirements  elso  pley  e  lerge  role  In  the  choice 
of  network  technology. 

A  network  implementer  nsy  choose  from  e  n\nber 
of  technologies  for  his  network.  Some  network 
Implemencers  might  choose  en  R/F  cable  (such  as  Che 
MITRE  bus),  or  radio  (such  as  ARPA's  Packet  Radio), 
or  the  use  of  coBmerclal  land  line  (such  as  Che 
ARPAnet),  to  name  juct  a  few.  It  Is,  therefore, 
not  rcelly  practlcel  to  ergue  for  one,  or  even  a 
few,  atenderd  protocols  at  the  network  layer.  The 
dlsedventeges  of  forcing  every  network  Co  use  the 
seme  or  extremely  similar  technologies  to  meet 
thel *  requirements  far  outweigh  the  advantage  of 
all  networks  being  able  to  Interconnect  at  the 
network  leyer,  especielly  when  a  stretegy  exists 
which  allows  Intereomunleetlon  between  networks 
without  Imposing  this  type  of  restriction  (one 
example  being  the  protocol  leyering  model  given  in 
this  paper). 

It  does,  however,  make  senee  to  argue  for  a 
standard  Interface  to  the  higher  layer  protocol. 
This  would  allow  reletively  eesy  conversion  between 
two  neCvorV  technologies  when  a  network  is  upgraded 
end  to  eome  extent  allows  for  transportability  of 
higher  layer  protocol  implementations. 

Standardization  of  the  Internet  Uyer 

The  Internet  layer  Is  where  the  real  impact 
of  ecenderdlsetlon  or  the  leek  thereof  occurs. 

There  are  three  alternatives  for  implementing 
the  Internet  leyer:  (1)  define  one  standard 
Internet  layer  protocol  to  be  used  within  one 
cooDunlceclon  cosBunity  (such  as  DoD);  (11)  do  not 
scanderdlze  at  all  end  allow  ell  networks  to 
Implement  their  own  Internet  layer  protocol, 
requiring  e  protocol  trenslstlon  at  the  gateway 
for  the  Internet  protocol;  and  (111)  do  not  even 
have  en  Internet  protocol  end  relegate  Che 
functions  to  either  the  network  leyer  or  the 
transport  leyer.  laiilementetlon  of  the  Internet 
leyer  procedures  in  the  network  leyer  protocol  now 
Implies  that  e  protocol  crensletlon  must  occur  at 
the  network  leyer.  The  net  effect,  from  a 
standerdisetlon  point:  of  view,  is  the  aasM  as 


altemetlve  (11).  Implementation  in  the  traneport 
layer  protocol  fells  under  the  category  of 
etandardizetion  for  transport  leyer  protocols. 

The  following  discussion  focuses  on  alternative 
(i),  e  eingle  Internet  protocol  etanderd  and 
alternative  (11),  the  leek  of  a  etanderd. 

There  are  a  nianber  of  advantages  to  a  standard 
Internet  protocol,  most  of  which  are  reflected  in 
the  size  and  simplicity  of  the  gateway.  A  standard 
protocol  leeds  to  a  conoon  approach  for  geteway 
construction,  where  many  copies  of  the  heart  of  one 
gstewey  (the  internet  protocol  Impiementetlon)  can 
be  made  and  eupplled  to  many  networks.  Networks 
%K>uld  be  responsible  for  interfscing  their  partic¬ 
ular  network  leyer  to  the  Internet  leyer.  These 
modules  should  already  exist  at  the  network's 
hosts,  where  a  gatewey-helf  Is  Implemented.  This 
approach  cen  reduce  the  net  development  costs  for 
gateways,  and  software  development  is  an  expensive 
proposition  (as  we  continue  to  experience).  It 
would  also  reduce  the  eoftwere  maintenance  costs. 

It  Is  possible  to  have  the  types  of  congestion 
control  baeed  on  dynamic  routing  dlcussed  earlier 
thet  would  probably  not  be  possible  if  protocol 
translation  were  required,  resulting  in  e  form  of 
more  reliable  eervlce  (reliable  here  In  the  sense 
that  a  gateway  Is  not  necessarily  a  single  point 
of  failure  or  congestion  for  a  user’s  co«unl- 
catlon) . 

The  gateway  does  not  have  to  worry  about 
connection  management  (which  Is  non-trlvlal)  as  it 
would  heve  to  do  if  the  procedures  of  this  layer 
are  relegated  to  the  transport  layer,  unless  a 
standard  transport  protocol  Is  Implemented.  This 
approach  malntelns  a  trensperency  to  ell  the  trans¬ 
port  leyer  procedures.  And  there  may  very  well  be 
more  then  one  transport  leyer  protocol  to  worry 
about.  This  resulte  In  a  much  simpler,  more 
efficient,  and  probably  more  reliable  gateway. 

On  the  other  hand,  one  standard  internet 
leyer  protocol  does  have  lis  dlsadventeges.  It 
requires  political  agreement  between  orgelnzetlons 
which  Is  not  always  easy  to  obtain,  especially 
*#hen  an  organisation  hes  already  Invested  resources 
to  go  In  a  different  direction.  Technical 
conformity  Is  required,  something  thet  all 
eklllful  protocol  designers  heve  trouble  living 
with.  And  It  provides  less  flexibility  to  change, 
at  least  et  the  Internet  leyer,  to  meet  new 
requirements. 

When  eome  of  the  procedures  which  we  feel 
ehould  be  In  the  Internet  leyer  hsve  been  relegated 
to  the  transport  leyer,  the  discussions  of  the 
section  on  transport  leyer  protocol  stenderdlzatlon 
also  apply. 

Standardization  of  the  Traneport  Uyer 

Stenderdlzatlon  of  the  transport  layer 
protocol  can  elso  have  e  significant  impect,  but 
not  as  lerge  es  thet  of  the  Internet  Ikyer  (unless 
the  Internet  layer’s  control  procedures  ere 
Implemented  et  the  transport  leyer).  It  Is 
possible  to  speak  about  etendardlzetlon  of  the 
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transport  laytr  within  a  cosoaunlty  alnct  It  la 
possible  to  define  a  set  of  closed  coimminltlcs 
which  share  a  conmon  network  or  set  of  networks. 

By  a  closed  community,  we  mean  thrt  a  boat 
belonging  to  that  connunlty  will  never  talk  to  a 
host  outside  of  the  community.  But,  when  two 
closed  comnunltles  which  have  their  own  "atandcrd" 
transport  layer  protocols  develop  a  requirement  to 
IntercooDunlcate,  their  protocols  are  no  longer 
standard  within  the  expanded  closed  coaounlty. 

They  will  face  the  same  difficulties  that  other 
non-standard  Implementetlons  will  face  when 
trying  to  Intercomnunlcare. 

There  are  three  alternatives  for  standardising 
transport  layer  protocols:  (1)  to  have  one 
standard  protocol  for  all  types  of  traffic;  (11) 
to  have  a  set  of  standard  protocols  based  on 
traffic  type  (as  defined  earlier);  and  (111)  to 
allow  each  network  tc  develop  their  own  transport 
layer  protocols,  l.e.,  not  to  standardise. 

Uhen  one  protocol  Is  defined  to  answer  the 
needs  of  all  users.  It  will  probably  end  up  not 
serving  any  very  well.  Its  generality  will  require 
e  large  amount  of  overhead,  resulting  In  potential 
severe  inefficiencies.  It  will  be  extremely  large, 
possible  eliminating  smaller  hosts  from  even 
Implementing  It.  This  approach  la  not  a  realistic 
alternative 


specific  applications.  It  does  not  have  to  compro¬ 
mise  Its  technical  approach  for  other  requirements. 
Also,  the  very  hard  to  get  political  agreements  are 
not  necesiaty  for  this  approach. 

Standardization,  Some  Concluding  Remarks 

We  are  In  basic  agreement  with  the  studies 
which  advocate  e  single  standard  Internet  layer 
within  e  cooBunlty.  We  also  contend  that  a  set  of 
transport  layer  protocols  la  what  la  required,  not 
just  a  reliable  date  protocol.  There,  unfortu¬ 
nately,  ere  no  hard  answers  yet  es  to  which  way  la 
best,  because  the  Inplementstlons  for  Internet¬ 
working  are  still  In  the  study  and  experimental 
phases.  The  model  we  have  presented  In  the  first 
pert  of  this  paper  la  consistent  with  the  ARPA 
approach  to  Internetworking. 

Should  DoD  choose  to  Implement  standard 
protocols  within  the  context  of  e  closed  conaunlty, 
it  la  Important  to  define  that  coanunlty 
judiciously.  There  ere  definitely  Impacts  on  DoD 
agencies  and  departments  from  the  way  other  members 
of  the  same  coaounlty  design  and  implement  their 
protocols. 

The  area  of  Interconnection  of  computer  net¬ 
works  la  an  exciting  and  Interesting  one,  but  many 
difficult  questions  remain  unanswered. 


When  protocols  are  based  on  the  type  of  ACmOULEDGMENT 

traffic,  one  protocol  per  type,  then  each  protocol 

can  be  optimized  to  handle  the  communication  The  author  wishes  to  recognize  the  contrl- 

characterlstlcs  of  the  traffic  for'whlch  It  was  butlone  of  the  many  Individuals  Involved  with  the 

Intended.  This  sltematlve  eliminates  the  need  for  ARPA  Internetworking  Project  end  within  the 

severe  overhead  end  size.  Of  course  protocols  will  various  agencies  of  the  Department  of  Defense, 

continue  to  be  enhanced,  but  as  long  as  one  main-  whose  conversations  with  the  author  made  this 

tslns  backward  compatlllllty,  this  should  not  P*pcf  possible.  Unfortunately,  they  are  too 

present  e  significant  problem.  A  host  will  slso  numerous  to  mention  here  by  name. 

not  have  to  worry  about  Implementing  many  different 
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motivation  fbr  burtonmrtlnf  ntfworiu  li  la  pravWt  ana 
or  mart  consbtcfii  aarrirci  la  the  mt  of  aam  of  the  taimoMMCietf 
netweriu.  To  •m'ictt  either  new  end-ta  end  aervkt  ^rMacob 

mull  he  defined  or  the  mrvlre  ^rotocoli  of  the  individual  nctworha  muM  he 
made  la  Interworh.  |r  either  caie  the  laeun  of  addreeaint,  randnt, 
hufrering,  fla»  control,  error  control,  and  aecorR)  muM  he  cowildtred. 
Two  cumpln  of  bitcrconnection  Mratcgy  are  eaamlned:  the  latercow 
nectlon  of  X.25  netwarhs,  and  the  hterconncction  of  ARf  A  raaeorch 
networU.  The  modeb  for  Interconnoctlao  of  MCworha  and  the  rail  of 
fotcmeCwoch  protocoli  art  diaenmad. 

INTRODUCTION 

HE  motivation!  for  conitructlnf  computer  communication 
natworks-data  and  program  exchange  and  tharing,  remote 
access  to  resources,  etc.-afe  also  motivations  for  Intercon* 
netting  networks.  This  follows  from  the  observation  that  the 
power  of  a  communication  system  is  related  to  the  number  of 
potential  participants. 

This  paper  first  discusses  a  few  key  concepu  involved  in 
computer  communication  networks.  The  view  that  computer 
networks  provide  an  interprocen  communiation  facility  is 
presented.  The  datagram  and  virtual  circuit  services  are  com* 
pared.  The  interconnection  device  or  gateway  is  discussed. 
The  relation  of  the  interconnection  issues  to  tht  open  systems 
architecture  is  described. 

in  this  paper,  two  approaches  to  internetworking  are 
diaracterized;  the  public  data  network  system  as  implied  by 
the  CCITT  X.7S  Recommendation  and  the  ARPA  experi* 
mental  internetwork.  These  two  systems  illustrate  the  virtual 
circuit  and  the  datagram  approaches  to  network  intercon* 
nection,  respectively.  The  vast  majority  of  the  work  on  inter* 
connecting  networks  falls  into  one  of  these  two  approaches. 

INTERPROCESS  COMMUNICATION 

While  discussing  computer  communication,  it  it  useful  to 
recall  that  the  communication  takes  place  at  the  request  and 
agreement  of  piocesses.  i.e.,  computirr  programs  in  execution. 
Processes  are  the  acton  in  the  computer  communication 
environment;  processes  are  the  sen  den  and  recciven  of  data. 
Processes  operate  in  host  computen  or  hoiu. 

The  protoeds  used  in  constructing  the  communications 
capability  provide  an  interproceu  communication  system. 
Fig.  I  shows  how  the  combination  of  the  network  and  the 
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under  Contract  DAHClS  72  C  0301,  ARFA  Order  2223. 

The  author  It  with  the  Information  Sciences  Iniiitutc.  Unlvtrnty  of 
Southein  Califemia,  Marina  del  Rey,  CA  90291. 


host  network  interface  (hardware  and  software)  can  be  viewed 
as  providing  an  interproceu  communication  system. 

When  a  new  host  computer  is  to  be  connected  to  an 
existing  network,  it  must  implement  the  protocol  layen 
necesury  to  match  the  existing  protocol  used  in  the  network. 
The  new  host  must  join  the  network-wide  interprocen  com¬ 
munication  system  so  the  processes  in  that  host  can  com¬ 
municate  with  processes  in  other  hosts  in  the  network. 

The  interconnection  of  networks  requires  that  the  processes 
in  the  hosts  of  the  interconnected  networks  have  a  common 
interprocen  communicalior.  system.  This  may  be  achieved  by 
converting  the  networks  to  a  new  interproceu  communication 
system,  by  converting  one  or  more  levels  of  protocol  to  new 
protoeds,  or  by  trs^islatlng  between  pairs  of  interprocess 
communication  systems  at  their  points  of  contact. 

DATAGRAMS  AND  CIRCUHS 

Two  types  of  service  are  commonly  discussed  as  appro¬ 
priate  for  the  network-provided  interproceu  communication 
service:  datagrams  and  virtual  circuits. 

Datagrams  are  orte-^hot  simple  messages.  They  are  in¬ 
herently  unreliable  since  they  travel  one-way  and  are  not 
acknowledged.  Datagrams  may  also  arrive  in  a  different 
order  than  tent  (at  lut*’  in  tom?  networb).  Datagrams  are 
simple  to  implement  since  L’‘e>  do  not  require  the  networb 
or  ptewayt  to  record  and  update  state  information.  Data¬ 
grams  must  carry  complete  addreu  information  in  each 
mesuge.  The  transmission  of  datagrams  by  a  procen  is  via 
tend  and  receive  actions. 

Virtual  circuits  (or  connections)  are  detipied  to  be  re¬ 
liable  and  to  deliver  data  in  the  order  sent.  Implementation  of 
virtual  circuits  is  complicated  by  the  need  for  the  networb 
or  gateways  to  record  and  update  state  information.  Virtual 
dreuitt  are  created  through  an  exchange  of  mesaget  to  set 
up  the  dreuit;  when  uw  terminates,  an  exrhange  of  metuges 
tean  down  the  dreuit.  During  the  data  transmission  phase,  t 
short  form  addreu  or  d.'cuit  identifier  may  be  uud  in  place 
of  the  actual  addreu.  To  use  t  virtual  dreuit  a  proceu  must 
perform  actions  to  cauw  the  virtual  dreuit  to  be  created  (call 
setup)  and  ierminated,  u  well  u  the  actions  to  send  and  re¬ 
ceive  data. 

Datagrams  provide  a  tranuction  type  service  while  virtud 
dreuitt  provide  a  connection  type  service.  Each  of  these 
services  Is  needed  in  a  general  purpose  communication  environ¬ 
ment.  Datapams  are  moat  effident  for  tranuction  type  in¬ 
formation  requests  such  as  directory  auistance  or  weather 
reports.  Virtual  dreuitt  arc  uuful  for  terminal  acceu  to 
interactive  computer  systems  for  fUe  tranife;  between  com¬ 
puters. 


0090-6778/80/0400-0604S00.7SO  1980  IEEE 


li)  1980  Il-i:i'.  Reprinted  with  permission,  from  IEEE  Transactions  on  Conuminications,  Vol.  ('om-28.  No.  4. 
pp.  604-611.  April  1980. 


a-133 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1985 


POSTEL:  NETWORK  INTERCONNECTION  APPROACHES 


P  HKCSS 
■  MST 

•I  IITMII  ItniPICt 

Fi|.  1.  CommunkatioBi  Mtwofk.  • 


a  Msr 

8  lartviT 

Fl|.  2.  InttrcoiuMciad  Mtwotki. 

gateways 

Two  or  more  networks  arc  connected  via  a  device  (or  pair 
of  devices)  called  a  gateway.  Such  a  device  may  appear  to  each 
network  as  simply  a  host  on  that  network  (Fig.  2). 

Some  gateways  simply  read  messiges  from  one  network 
(unwrapping  them  from  that  network's  packaging),  compute 
a  routing  function,  and  send  messages  into  another  network 
(wrapping  them  in  that  network's  packaging).  Since  the  net* 
woflu  involved  may  be  implemented  using  different  media, 
such  u  leased  lines  or  radio  transmission,  this  type  of  gateway 
b  called  a  media<onversion  gateway. 

Other  pteways  may  translate  the  protocol  used  in  one 
network  to  that  used  in  another  network  by  replacing  mes* 
sages  received  from  one  network  with  different  messages  with 
the  same  protocol  semantics  sent  into  another  network.  This 
type  of  pteway  is  called  a  protocol-translation  gateway. 

It  should  ^  clear  that  the  distinction  between  media- 
conversion  and  protocol-translation  is  one  of  degree:  the 
ncdia<onvcrsion  gateways  bridp  the  pp  between  differing 
link  and  physical  level  protocols,  while  protocc^-translation 
pieways  bridge  the  pp  between  difTering  network  and 
Higher  level  protocols. 
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The  translation  approach  to  network  interconnection 
raises  several  Issues.  Success  in  protocol  translation  seems 
inversely  correlated  with  the  protocol  level.  At  the  lower 
levels,  protocol  translation  causes  no  problems  because  the 
physical  level  and  link  levels  are  hop-by-hop  in  nature.  It 
should  be  noted,  though,  that  different  protocols  even  at 
these  low  levels  may  have  impact  on  the  reliability,  through¬ 
put,  and  delay  characteristics  of  the  total  communication 
system. 

At  the  network  and  transport  levels,  the  issues  of  mesup 
size,  addressing,  and  flow  contre^  become  critical.  Unleu  one 
requires  that  only  messaps  that  can  be  transmitted  on  the 
network  with  the  smallest  maximum  meuap  size  be  sent,  one 
must  provide  for  the  fragmentation  and  reassembly  of  mes- 
ups.  That  is,  the  division  of  a  long  mesup  into  parts  for 
transmission  through  a  small  mesup  size  network,  and  the 
reconstruction  of  thou  parts  into  the  original  mesuge  at  the 
destination.  The  translation  of  addresus  is  a  difflcult  problem 
when  one  network  or  transport  level  protocol  provides  a  larger 
addren  space  than  the  corresponding  protocol  to  be  translated 
to.  When  tnd-t»«nd  flow  control  mechanisms  are  uud,  u 
they  commonly  are  in  transport  level  protocols,  difllculties 
ariu  when  the  units  controlled  arc  different.  For  example, 
when  one  protocol  controls  octets  and  the  corresponding 
protocol  controls  letters.  More  difficulties  ariu  with  potential 
difference  in  the  model  of  flow  control.  For  example,  a 
difference  between  pre-  and  postallocation,  or  between  the 
allocation  of  buffer  space  and  the  allocation  of  transmission 
rate. 

At  higher  levels,  the  problems  are  more  difflcult  becauu 
of  the  increaud  state  information  kept  and  the  lower  likeli¬ 
hood  of  one-to-one  translation  of  individual  protocol  mes- 
ups.  A  further  difflculty  is  that  each  level  further  multi¬ 
plexes  the  communication  so  that  each  connection  or  stream 
or  dunnel  or  virtual  circuit  must  be  uparately  translated. 
It  should  be  noted  that  neither  of  the  specifle  interconnec¬ 
tion  approadies  discusud  in  this  paper  attempts  higher  level 
proto<^  translation. 

Gateways  may  be  thought  of  u  having  a  **hair  for  each 
network  they  interconnect.  One  could  model  the  operation 
of  a  gateway  u  having  each  gateway-half  contain  procedures 
to  convert  from  a  network  spedfle  protocol  into  a  standard 
protocol  and  vice  veru  (Fig.  3). 

REUTION  TO  OPEN  SYSTEMS  ARCHITECTURE 

In  relation  to  the  open  systems  architecture,  the  inter¬ 
connection  of  networks  focuus  on  levels  3  and  4  ( 1  ] . 

To  review,  the  open  systems  architecture  defines  the 
following  levels  of  protocol: 
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Fig.  3.  Gateway  kahtt. 


The  lower  levels,  the  physicil  end  the  link  levcli,  trt 
hop-by*hop  in  nature  and  present  no  interconnection  touts 
in  terms  of  compatibility,  tlthou|h  there  may  be  aome  per* 
formance  concerns. 

The  higher  levels,  the  session  level,  the  presentation  level, 
and  the  application  level,  have  so  many  compatibility  require* 
ments  that  it  seems  quite  unlikely  that  interconnection  of 
different  protocols  at  those  levels  will  be  workable. 

Thus,  it  is  at  the  network  level  and  the  transport  level  that 
the  interconnection  of  networks  finds  toues  of  concern. 

The  network  level  conesponds  to  the  interface  to  data* 
gram  service,  and  the  transport  level  corresponds  to  the  inter* 
face  to  virtual  circuit  service. 

In  some  networks,  the  network  level  and  datagram  service 
have  been  hidden  from  the  user,  forcing  consideration  of 
network  interconnection  at  the  transport  level. 


F%.4.  rON  virtual  draih. 
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INTtRCONNECnON  OF  X,2S  NETWORKS 
Atroduerion 

The  public  data  networks  (PDN*s)  that  follow  the  CCYTT 
X2S  Recominendation  (2l  are  to  be  interconnected  via  an 
interface  ipedfied  in  CCITT  Recommendation  X7S  (3]. 
Recommendation  X2S  specifies  the  interface  between  the 
customer's  equipment,  called  the  data  terminal  equipment 
(DTE);  and  the  network  equipment,  called  the  data  circuit* 
terminating  equipment  (DOE).  Recommendation  X.2S  impUes 
a  virtual  circuit  operation.  Thus,  the  FDN's  offer  an  Interface 
to  a  virtual  circuit  transport  level  protocol.  Fig.  4  shows  the 
model  of  a  PDN  virtual  circuit. 

The  Interface  between  two  FDN's  specified  tai  Recom¬ 
mendation  X.7S  is  quite  simUar  to  that  in  Recommendation 
X.2S.  The  equipment  bn  either  side  of  this  interface  is  c^ed 
a  signaling  terminal  (STE).  The  STE-STE  interface  Is  much 
like  the  DTE-DCE  interface.  The  STE-STE  Interconnection 
Is  a  split  gtteway  with  each  pteway-half  In  a  physical  device 
controlled  by  the  FDN  connected  to  that  ptewsy*half.  Fig.  S 
shows  the  interconnection  of  FDN's. 

The  interconnection  of  FDN's  via  X.7S  Interfaces  results 
In  a  series  of  virtual  circuits.  Each  section  is  a  distinct  entity 
with  separate  flow  contred,  enor  recovery,  etc.  Fig.  6  shows  a 
FDN  transmission  path  with  two  virtual  circuits  (VC's)  and 
five  separate  flow  control  (FC)  steps. 


K,  VC, 


rc,  rC|  rC(  re,  re, 

VC  VtrtMl  Cirtatl 

rc  riM 

FIrI.  PDN  trsMmiMlMi  pth. 

AddratOtg 

The  address  field  la  variable  In  length  up  to  IS  digits,  with 
each  digit  coded  In  a  4  bit  Reid.  The  maximum  address  Is  then 
60  bitt  (about  I  octeu). 

/touring 

The  user  has  no  faifluence  over  routing  used.  To  create 
the  series  of  virtual  circuits,  a  series  of  call  setups  establishes 
a  fixed  route  (between  pairs  of  STE’i  a!  least).  Sute  Informa¬ 
tion  must  be  kept  for  each  call  in  the  icvurc*  enrf  Hfttinttiao 
DTE's  and  DCE's  and  in  each  STE  in  the  routt. 

Buffering  end  Flow  Control 

Each  portion  of  the  toul  path  Is  a  distinct  virtual  circuit. 
Each  virtual  circuit  has  an  Independent  flow  control  (and 
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pirticulif  10  thti  PDN).  In  tddition,  ihert  It  flow  control 
■cross  cich  STE-STE  Interfice.  AU  Ihii  flow  control  U  on  • 
per  call  bisis.  Th»  stepwise  flow  control  mey  Introduce 
deity  in  the  total  path  that  could  be  avoided  with  in  end*to> 
end  scheme. 

There  are  tome  concerns  about  the  interaction  of  two 
types  of  flow  control  im^emented  in  PDN’s.  One  type  lUows 
one  message  in  transit  from  source  DCE  to  destination  DCE 
at  any  one  time.  The  other  allows  multiple  mesuges  to  be 
in  transit,  the  number  being  determined  by  the  flow  control 
window. 

Acknowlediment 

Each  portion  of  the  total  path  has  an  acknowledgment. 
The  user  to  network  interface  also  has  an  acknowledgment. 
This  local  acknowledgment  means  only  that  the  first  PDN 
hat  accepted  the  message  for  transmission,  not  that  it  has 
arrived  at  the  destination. 

Ricovtry 

The  X.25  and  X.75  Recommendations  do  not  specify 
how  the  PDN’s  deal  with  errors  internally.  If  unrecoverable 
errors  occur,  the  network  will  signal  a  Reset,  which  apparently 
meant  that  the  virtual  circuit  ttUl  exhu.  but  the  flow  control 
it  reset  and  messages  may  have  been  lost.  More  serious  enon 
result  in  the  call  being  cleared. 

Because  of  the  fixed  route  nature  of  the  multinetwork 
path,  an  STE  failure  disrupu  the  eommunteation. 

Sicurity 

The  X.25/X.75  Recommendations  do  not  provide  any 
security  features. 

Header  Snuctttn 

Once  the  call  Is  established,  a  header  is  only  3  octets.  The 
call  setup  headers  are  substanUaUy  longer,  typically  20  octets, 
but  possibly  as  large  at  166  octets.  There  it  a  tradeoff  between 
header  size  and  state  Information  kept;  in  the  PDN*s,  the 
tradeoff  hat  been  made  toward  small  headers  and  large  state. 
The  details  of  the  headers  are  shown  in  Appendix  1. 

Summary 

The  most  important  aspect  of  the  intcrconrwction  of 
PDN*s  Is  that  service  provided  to  the  using  process  is  a  virtual 
dreuit  with  essentially  the  same  properties  a  dn^e  PDN  woidd 
have  provided.  This  Is  done  by  concatenating  a  series  of 
virtual  dreuits  to  provide  the  total  path,  resulting  in  a  fixed 
route  through  a  set  of  network  interconisectlon  points. 

INTERCONNEaiON  OF  ARPA  RESEARCH  NETWORKS 
htro^etion 

The  ARPA  sponsored  research  on  taterconnectioni  of 
networks  has  let  to  a  two4evei  protocol  to  support  the  equiva. 
lent  function  of  the  PDN*i  X.25/X.75  service.  The  ARPA 
sponsored  work  on  networks  has  developed  an  internet  prol»> 
eol  (IP)  |4l .  and  a  transmission  control  protocol  (TCP)  |5) . 

TCP  is  a  lopcal  connection  transport  protocol  and  Is  a 
level  4  protocol  tot  the  OSA  model  of  protocol  structure. 
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Fig.  7.  Eiid>t»«nd  eoMMCtlea. 


The  IP  is  a  datagram  protocol.  The  collection  of  intercon¬ 
nected  networks  is  called  an  internet.  IP  Is  the  network  proto¬ 
col  of  the  internet  and  this  to  a  level  3  protocol  in  the  OSA 
model.  The  actual  networks  used  are  of  various  kinds  (e.g.. 
the  ARPANET,  radio  networks,  ntellite  networks,  and  ring 
or  cable  networks)  and  are  referred  to  u  local  networks  even 
thou^  they  may  span  continents  or  oceans.  The  interface  to 
a  local  network  is  a  local  rtetwork  protoed  or  LNP.  Fig.  7 
shows  the  model  of  an  end-to^d  cormection. 

In  the  ARPA  model,  the  networks  taterconnect  vto  a 
tingle  device  called  a  gatevray.  A  gateway  to  a  host  on  two 
or  more  networks.  Fig.  I  shows  the  ARPA  model  of  the 
interconnection  of  networks. 

Each  network  addresses  a  gatevray  on  it  in  the  same  way  it 
addresses  any  other  host  on  It.  The  information  required  to 
deliver  a  message  to  a  destination  in  the  internet  to  carried  In 
the  IP  header.  The  IP  Is  Implemented  in  the  gateways  and  In 
hosts.  A  sending  host  prepares  a  datagram  (which  to  an  IP 
header  and  the  original  mesuge)  and  then  selecu  a  gateway 
in  its  own  net  to  forward  the  dataram.  The  sending  host 
then  sends  the  datagram  wrapped  fat  a  local  network  packet 
to  that  gateway. 

A  gateway  receives  a  packet  from  one  of  the  local  net¬ 
works  to  which  It  to  attached,  and  unwraps  the  IP  data¬ 
gram.  The  ptevray  then  examines  the  IP  header  and  deter¬ 
mines  the  next  pteway  (or  destination  host)  address  in  one 
of  the  local  networks  It  to  directly  connected  to.  The  pte- 
way  then  sends  the  daugram  with  its  IP  header  in  a  new  local 
net  packet  to  that  pteway  (or  host). 

The  IP  has  no  provision  for  flow  control  or  error  control 
on  the  data  portion  of  the  messap  (the  IP  headers  are  check- 
summed).  There  are  no  acknowledgmenu  of  IP  mesuges. 
The  IP  Is  simple  and  the  pteway  may  be  Implemented  in 
smaU  machines.  A  key  point  Is  that  a  pteway  has  no  state 
information  to  record  about  a  mesup.  At  the  IP  level,  there 
are  no  connections  or  virtual  dreuits. 

The  IP  does  not  povide  a  urvice  equivalent  to  the  PDN*s 
X25/X.75.  To  povide  that  typ  of  end-to-end  reliable 
ordered  debvery  of  dau  the  ARPA  Internet  uses  TCP. 
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Fi|.  f.  ARPA  model  of  uenmution  peth. 

TCP  uses  end-to-end  mechinisms  to  ensure  rcliible  ordered 
delivery  of  data  over  a  logical  connection.  It  uses  flo>v  control, 
positive  acknovbrledgments  with  time  out  and  retransmission, 
uquence  numbers,  etc.,  to  achieve  these  goals.  Fig.  9  shows 
the  conceptual  transmission  path  in  this  interprocess  com¬ 
munication  system,  pointing  out  the  datagram  (DC)  path 
between  the  IP  modules  and  the  virtual  circuit  path  between 
the  TCP  modules  at  the  source  and  destination  and  the  flow 
control  (FC)  at  that  le^l. 

ARPA  has  used  these  techniques  to  interconnect  several 
very  different  networks  including  the  ARPANET,  packet 
radio  nets,  a  satellite  net.  and  several  local  networks. 

Addrewng 

The  size  of  the  address  in  this  eiperimental  system  is 
fixed.  The  IP  provides  a  one  octet  network  field  and  a  three 
octe:  host  field.  Also  a  one  octet  protocol  identifier  in  the 


IP  header  may  be  considered  address  information.  The  TCP 
provides  a  two  octet  port  field.  The  total  of  the  address 
length  is  then  Kven  octeu.  Provision  has  been  made  for  a 
host  to  have  several  addresses,  so  the  host  field  is  sometimes 
called  the  logical  host  field.  The  total  address  is  the  con¬ 
catenation  of  the  network,  host,  protocol,  and  port  fields. 
Routini 

Normally,  the  user  has  no  influence  over  the  route  used 
between  the  pteways.  There  is  no  call  setup  and  the  route 
may  vary  from  one  mesup  to  the  next.  No  sute  information 
is  kept  in  the  pteways. 

A  user  might  insert  a  source  routing  option  in  the  IP 
header  to  cause  that  particular  mesup  to  be  routed  throu^ 
spedfle  pteways. 

Buffering  end  Flow  Control 

There  is  no  flow  control  mechanism  in  the  IP.  The  pte¬ 
ways  do  not  control  the  flow  on  connections  for  they  are 
unaware  of  connections  or  any  relation  between  one  mesuge 
and  the  next  mesup.  The  pteways  may  protect  themselves 
apinst  conpstion  by  dropping  mesups.  When  a  pteway 
drops  a  mesuge  became  of  conpstion,  it  may  report  this 
fact  to  the  source  of  the  mesup. 

The  TCP  uses  end-to^nd  flow  control  using  windows 
on  a  per  logical  connection  basis. 

Acknowledgment 

The  IP  has  no  provision  for  acknowledgments.  The  TCP 
uses  acknowledgments  for  both  enor  control  and  flow  control. 
The  TCP  acknowledgments  are  not  directly  available  to  the 
mer. 

Recovery 

Erron  in  a  network  or  pteway  result  in  a  mesuge  being 
dropped,  and  the  under  may  or  may  not  be  notified.  This 
inherent  unreliability  in  the  IP  level  allows  it  to  be  simple 
and  requires  the  end-to^nd  uu  of  a  reliable  protocol. 

TCP  provides  the  reliable  end-to-end  functions  to  recover 
from  any  lost  mesuges.  The  TCP  uus  a  positive  acknowl¬ 
edgment.  time  out.  and  retransmission  scheme  to  ensure 
delivery  of  all  data.  Each  mesup  is  covered  by  an  end-to- 
end  checksum. 

Because  of  the  potential  of  alternate  routing,  the  end-to- 
end  communication  may  be  able  to  continue  despite  the 
failure  of  a  pteway. 

Security 

The  IP  provides  an  option  to  carry  the  ucurity,  precedence, 
and  mer  poup  information  compatible  with  AUTODIN  II. 
The  enforcement  of  these  parameters  is  up  to  each  network, 
and  only  AUTODIN  11  is  prepared  to  do  to. 

The  TCP  end-to4nd  checksum  covers  all  the  address 
information  (source  and  destination  network,  host,  protocol, 
and  port),  so  if  the  checksum  test  is  successful  the  address 
fields  have  not  beer,  corrupted. 
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The  IP  header  is  20  octets  (plus  options,  if  used),  but 
there  is  no  call  setup  and  no  gateway  state  information. 
Thus,  at  the  IP  level,  the  header  size  versus  state  information 
tradeoff  has  been  made  toward  large  header  and  little  (no) 
state  information. 

The  TCP  header  is  20  octeu  (plus  option,  if  used).  There 
is  a  connection  establishment  procedure  called  the  **thrce-wiy 
handshake,**  and  signiHcant  state  information  is  kept.  In  this 
case,  there  are  both  large  headen  and  large  state  ubies.  The 
details  of  the  headers  are  shown  in  Appendix  11. 

Summary 

The  ARPA  networks  are  interconnected  by  using  a  com* 
mon  datagram  protocol  to  provide  addressing  (and  thus 
routing)  information  and  an  end'to^nd  transport  protocol 
to  provide  reliable  sequenced  data  connections. 

This  model  has  evolved  from  the  ARPANET  experience. 
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In  particular  from  the  internetwork  protocol  model  sug¬ 
gested  in  a  paper  by  Cerf  and  Kahn  [6] . 

CONCLUSION 

Both  the  PON’s  and  the  ARPA  networks  are  intercon¬ 
nected  by  establishing  standard  protocols.  The  PON’s  provide 
a  virtual  circuit  service  by  concatenating  the  virtual  circuit 
service*  of  the  individual  netwoi’iu.  The  ARPA  .>tetwQfks  use 
two  levels  of  protocol  to  provide  both  datagram  and  virtual 
circuit  services. 

Additional  discussion  of  the  interconnection  of  PON’s  is 
provided  in  (7),  (8).  In  another  paper  in  this  issue  Boggs 
tr  if.  present  in  detail  another  example  of  network  inter¬ 
connection  using  the  datagram  approach  (9) . 

The  Issues  of  network  interconnection  have  been  discussed 
for  at  least  S  yean  (for  example,  McKenzie  (10)).  The  recent 
expositions  by  Sunshine  [11],  Cerf  and  Kintein  (12).  and 
Cien  and  Zimmermann  (13) ,  are  particularly  recommended. 


APPENOIXI 


X.7SHEAOER  FORMATS 

The  call  request  and  the  data  packet  formats  are  illustrated  here.  These  typify  the  X.7S  packet  formats. 
All  the  X.7S  packets  are  the  same  in  the  Rnt  two  octeu.  The  format  field  indicated  the  type  of  packet. 

Cl//  Request 

The  call  request  packet  is  variable  in  length  from  a  practical  minimum  of  1 1  octets  to  an  unlikely  maxi¬ 
mum  of  160  octets. 


PerBSt 

Channel  Croup 

Channel 

■uBber 

J _ !!!? _ 1 

1  Sre  Adr  Len 

Oat  Adr  Len  I 

Deatlnetlon  Address  1 

then 

Souret  Address  I 
(  ■aiUuB  tS  eetets  ) 


0  ^  0  I  Metuork  Utilltlea 

■eiuork  Utilities  Oats 
(  aatiBUB  62  eeteta  ) 

0  '  0  I  User  feeimiea  ten" 

User  raeilitiea  Data 
(  BstlBUB  62  eetets  ) 


User  Date 

(  BsxlBUB  16  eetets  ) 
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Tnnsmittion  Control  Protocol 

The  basic  TCP  header  is  20  octets,  and  the  header  may  be  up  to  60  octeu  long  if  options  are  used. 


Souret  Pert 


Ottilnttlon  Port 


Soquonet  Nuabtr 


DfttiORtlen  Addrott 


Ddtd  Offsdt 

Control  Pltgt 

Vindea 

ChtektiM 

Urgtnt 

Polnttr 

Data 


REFERENCES 

ftl  H.  ZiHWWfmw.  "TV  ISO  nfwtwct  w»adirl.“  »>*  mm.  pp 

{2!  "lUcommviidMM*  X  2S1fM«n«rt  Am  rnmuiri  tqwipimiM 

(DTE)  mi  Am  ctrcvit  irmiiiKKic  <HM>p<wwi  (OCEi  Sv 
ifNniMif  m  am  pacUt  me*  m  pmirn  4m  WMmrtt,**  i»  CC/JT 
Otmmft  wi  y.  bM  TfkfiiMt  mA  Takfnpii  Cmmkmhm 
CommiWf.  Gcntvt.  S*im*Ua4 

(3)  **^eoowi  for  prmoKmtf  RocomwtwAmoii  X  TS  ea  iiainmtwinl 
Hwrwmiuia  brn»m«  pacMt  twitch*  eaia  Mfw«ra».'*  m  CCTTT  StvAy 
Omp  Vl)  CentnbiMM  m  JtP,  Im  TtltphoM  wd  Ttivgrapa 
CwMwtt>«i*t Cammiwm. Gcar^o.  SwaigrtiAe.  Moy  ITTI 

(«t  OARPa.  "000  mMiti  imrmot  iormcoI."  ICN'Ilt.  Dtirmc 
A*wh*  RrwwtH  Rrojectt  Afowey.  fw  IHO 

(S)  OaRPA.  "OOO  amlati  wmamumm  mmol  pwmeri.”  0&^'i2a. 
DtfcdM  AA«anc*  tmwrh  PtofKtt  Afmy.  )afi  (HO. 

141  V  Out  and  i  Kolm.  "A  promrol  far  pmUs  mfwmt  rntncrmi. 
mmmwmrttUTrmt  Cmmm  .*1  COM  U.pp  4J1-44I.M»y 
tf74 

(T}  G  Gieumafi.  A.  Hmchky.  omI  C  Sawahtm.  "ItOMn  m  wammmaal 
py4(kdtt»iittwora(H-‘'C««y*  .U»rw**i.  •«*.  3.  pp  354>246.  Supt. 
itn 

:•!  V  OCiccio.  C-  J  P»«,  rnd  t  Mummi.  *‘AlMVMii««»  lor 


MumwiWKiioa  of  pwMie  pachoi  iwnefimf  4m  Mfwoiit."  m  Pmr 
luoaOrnaCammim  JrV.ACM/TEEE.No*  i*H.pp  120.123 
IP)  D  iott*- 1  SAoch.  E  Talk,  and  R  Mmcaifr.  "hip  A*  maematu  art 
archMacnirr.'’ dua  laaaB.  pp  412.424 

(10)  A.  IHcJCmm.  "Soma  eoanpiMr  mfwoA  iHig^pimaCTiow  ttawat.**  w 
Prwr.  Nm  Cmpm  CH .  AP1PS.  If34.  pp  U7.434 

iiwaaa  •.  hmial  mEttmd  dat  §  S  wd  M  S 
daract  m  tMfiMrrwc  and  *t  P»  0  drtma  m 
aaaapMfr  mam  awa  da  UM««nay  of  Caitlonua. 
L«Aiit*l<n 

Ha  haa  woAad  far  dia  Mmc  Cmponnmi  m 
McLmii.  VA.  and  SRI  lammanewal  m  Manlo  Paii. 
CA  At  l?Cl,*  V  •*  ^  ?f 

da  ARPANET  Natwmi  McaawrtmaM  Camat  a* 
da  MauKatwa  af  Ar  Rm  baa  ••  da  ARPaNEI 
Swat  dai  wia.  ha  haa  panaipaiad  «  da  dt«cl- 
opMM  ol  many  *  da  H<thaf  a«al  pRMocoh  tttad  «a 
da  ARPANET  He  a  ewnmiy  a  Campuar  Scamia  a  da  UhCTitfcmadoii 
Scieian  batista  m  Manna  del  Ray.  Ca,  whanc  hia  maaich  focuan  m  da 
NiBicmMactiaa  of  coawMar  aaiwoita 


EvlPLEMENTATION  GUIDELINES 


261 

The  ARP  A  Internet  Protocol 


Jonathan  B.  Postel,  Carl  A.  Sunshine  and 
Danny  Cohen 

mionnatton  Sdtnct*  institute,  Unhenity  ofSoulheni  Cali¬ 
fornia.  46  76  Admiralty  Way.  Marina  del  Rey.  California 
90291.  USA 

A  variety  of  computer  networks  are  interconnected  by 
gateway  computers  in  the  ARPA  internetwork  system.  Pro* 
cesses  on  different  networks  may  exchange  messages  with 
each  other  by  means  of  an  Internet  Protocol  which  must  be 
implemented  in  each  subscriber  (host)  computer  and  in  the 
pteways.  The  Internet  Protocol  is  a  relativety  simple  proto¬ 
col  that  provides  for  (he  delivery  of  individual  messages 
(datagrams)  with  high  but  not  perfect  rcliabtlity.  Thb  toter* 
net  Protocol  does  not  replace  the  existing  protocol  in  any 
network,  but  is  used  by  processes  to  extend  the  mnp  of 
communications.  Mnuges  in  Internet  Protocol  are  trans¬ 
mitted  through  any  individual  network  by  encapsulating 
them  in  that  network's  protocol.  This  paper  presents  an  over¬ 
view  of  the  Internet  Protocol  and  the  operation  of  the  pte- 
way  computers  in  the  ARPA  internet  system. 

Keyutords  Pfoiocol.  ARPA  Net.  Internetwork.  Data¬ 
gram.  Oaieway. 
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1.  IntTOduCtKMl 


Tnc  fimtiy  of  contpuicr  networks  developed  for 
the  United  Stites  Defense  Advanced  Research 
Projects  Agency  (DARPA)  represents  one  of  the 
largest  and  most  diverse  internetwork  systems 
currently  in  operation.  Ilie  basic  approach  to  inter¬ 
connecting  thb  variety  of  networks  was  developed 
over  several  years,  and  has  resulted  in  the  definition 
of  an  Internet  Protocol  (IP)  (Ij.  This  paper  is 
intended  primarily  to  document  the  details  of  the  IP 
in  tlte  open  literature,  and  secondarily  to  provide  a 
brief  discussion  of  the  major  design  tradeoffs  which 
caused  the  IP  to  take  its  current  form. 

Section  2  presents  an  overview  of  the  DARPA 
approach  to  interconnection  and  the  operation  of  IP. 
Section  3  details  IP's  main  features,  while  some  addi¬ 
tional  options  are  treated  in  section  4.  Section  5 
summaries  the  IP  and  otJier  functions  performed  in 
the  fflttrwayi  which  interconnect  networks.  Section  6 
diKusses  the  major  design  choices  in  developing  IP. 
Section  7  outlines  several  questions  and  extensions 
requiring  further  work. 
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2.0vmiew 

Since  the  development  of  the  ARPANET  in  the 
eiriy  I970’i,  i  variety  of  new  pKket  swritching  net* 
work  technologies  and  operational  networks  have 
beer,  developed  under  DARPA  sponsorship,  including 
utellite,  packet  radio,  and  local  networks.  In  order  to 
allow  processes  on  different  networks  to  communi¬ 
cate  with  each  other,  a  means  .^or  interconnecting  net¬ 
works  hu  been  developed  without  requiring  changes 
to  the  internal  operation  of  any  network. 

The  method  chosen  for  interconnecting  networks 
makes  minimal  demands  on  individual  networks.  To 
facilitate  inclusion  of  a  wide  variety  of  networks, 
each  net  is  required  to  provide  only  a  minimal  data- 
pvn  level  of  service  (i.e.  to  deliver  individual  pKkets 
of  moderate  length  between  its  users  with  high  but 
not  perfect  reliability).  Networks  are  inter-connected 
by  pteway  computers  that  appear  to  be  local  sub¬ 
scribers  on  two  or  more  nets.  The  pteways  arc 
responsible  for  routing  traffle  across  multiple  net¬ 
works,  and  for  forwarding  messaps  acrou  each  net 
using  the  packet  transmission  protocol  in  each  net¬ 
work.  The  pteways  provide  a  point-to-point  internet 
datagram  service  by  concatenating  the  datagram 
services  available  on  each  individual  net.  Such  a 
system  of  interconnected  networks  has  been  called  a 
Gireiter  (2|. 

This  approach  allows  the  interconnection  of  net* 
works  that  have  sipificantly  different  internal  proto¬ 
cols  «id  performance.  The  networks  in  the  ARPA- 
Catcnct  were  originally  designed  u  independent  enti¬ 
ties.  In  the  Catenet  approach  no  changes  are  required 
in  the  internal  functions  of  any  network. 

Gateways  provide  an  inicmet  service  by  means  of 
an  Internet  ^otocol  (IP)  that  deHnes  the  format  of 
internet  packets  and  the  rules  for  performing  inter¬ 
net  protocol  functions  based  on  (he  control  informa¬ 
tion  (internet  header)  in  these  packets.  IP  must  be 
implemented  in  host  computers  (subscribers)  enppd 
in  internet  communication  u  well  as  in  the  pteways. 
Gateways  also  use  a  pteway-to-pteway  protocol  to 
e.xchanp  routing  and  control  information. 

IP  provides  for  transmit  ling  daugrams  from  an 
mtemet  source  to  an  internet  destination,  potentially 
in  another  net.  IP  also  provides  fur  frafmentanurt  and 
rttsstmbly  of  long  daiagrams.  if  necessary,  for  uans- 
mission  through  networks  with  small  packet  sue 
Umiu. 

IP  *4  purposely  limited  in  scope  lo  provide  only 
the  function  necessary  lo  deliver  datsframs  over  an 


interconnected  system  of  networks.  The  functions  of 
flow  control,  sequencing,  additional  data  reliability, 
or  other  services  commonly  found  in  host-to-host 
protocols,  and  multidestination  delivery  capability  or 
other  services  are  purposely  left  for  higher  level 
protocols  to  provide  as  necessary.  This  allows  the 
higher  levels  to  be  tailored  to  specific  applications, 
and  allows  a  simple  and  efficient  implementation  of 
IP. 

2.1.  Place  in  Protocol  Hierarchy 

As  described  above,  IP  functions  on  top  of.  or 
uses,  the  packet  transmission  protocol  in  each  indivi¬ 
dual  network.  IP  is  used  by  higher  level  end-to-end 
protocols  such  u  a  reliable  transport  protocol.  e.g.. 
Transmission  Control  Protocol  (TCP)  [3|  in  the 
ARPA-Catenet  or  a  ~real  time**  protocol,  e.g.,  for 
packet  speech. 

As  shown  in  Figure  I ,  IP  is  the  only  level  in  the 
protocol  hierarchy  where  a  single  common  protocol  is 
used.  By  locating  this  point  of  convergence  at  the 
internet  datagram  level,  the  Catenet  approach 
preserves  the  flexibility  to  incorporate  a  variety  of 
individual  networks  and  protocols  providing  packet 
transmission  below  IP,  while  remaining  general  and 
effleient  enough  to  serve  u  a  common  basis  for  a 
vaiiety  of  higher  level  protocols.  With  this  approach. 
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gateways  need  only  provide  datagrain  service,  and 
remain  relatively  simple,  inexpensive,  and  efficient. 

2.2.  Model  of  Operation 

The  Internet  Protocol  provides  two  major  func¬ 
tions:  routing  a  datagram  across  successive  networks 
to  its  internet  destination  addreu,  and  iVagmentation/ 
reassembly  of  large  packets  when  needed  to  cross  nets 
with  small  packet  size  limits.  To  accomplish  this,  an 
IP  module  must  reside  in  each  host  engaged  in  inter¬ 
net  communication  and  in  each  gateway  that  inter¬ 
connects  networks.  The  following  scenario  describes 
the  progress  of  a  datagram  from  source  to  destination 
(assuming  one  intermediate  gateway  is  involved -see 
Figure  2). 

The  basic  notion  is  encapsulation.  The  data  to  be 
transmitted  must  pass  through  a  variety  of  network 
environments.  To  do  this  the  data  is  encapsulated  in 
an  internet  datagram,  to  send  the  datagram  through 
an  individual  network,  it  is  in  turn  encapsulated  in  a 
local  network  packet,  and  extracted  at  the  other  side 
of  that  network  where  it  is  decapsulated  from  the 
first  network  protocol  and  is  encapsulated  in  the 
second  network  protocol.  Thus  the  model  is  a  series 
of  encapsubiion/^xtractions,  not  translations.  This 
encapsulation  is  an  information  preserving  transfor¬ 
mation,  all  the  information  is  preserved  even  if  the 
individual  network  cannot  make  use  of  it. 

The  tending  internet  user  (typically  a  higher  level 
protocol  module  such  as  TCP)  prepares  its  data  and 
call.!  on  its  local  IP  module  to  tend  the  data  as  a  data¬ 
gram,  passing  the  destination  address  and  other 
parameters  as  arguments  of  the  call. 

The  IP  module  encapsulates  the  data  in  a  datagram 
and  fills  in  the  datagram  header.  The  IP  module  exa¬ 
mines  the  internei  destination  address,  if  it  is  on  the 
same  network  at  this  host,  it  tends  the  datagram 
direct'  to  the  destination,  if  the  datagram  is  not  on 
die  ume  network  ihen  the  IP  module  sends  the  data- 
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gram  to  a  gateway  for  forwarding.  The  selection  of 
which  gateway  to  send  the  datagram  to  is  an  internet 
routing  decision. 

The  local  network  interface  (note  that  from  the  IP 
point  of  view,  a!)  actual  networks  are  “local”  even  if 
they  span  across  the  world)  creates  a  local  network 
packet  with  its  own  header,  and  encapsulates  the 
datagram  (complete  with  internet  header)  in  it.  then 
sends  the  result  via  the  local  network. 

The  datagram  arrives  at  a  gateway  host  encapsu¬ 
lated  in  the  local  network  packet.  The  local  network 
interface  extracts  the  IP  datagram  and  turns  it  over  to 
the  IP  module. 

The  IP  module  determines  from  the  internet 
destination  address  that  the  datagram  should  be  for¬ 
warded  to  another  host  in  a  second  network.  The 
IP  module  uses  the  local  portion  of  the  destination 
address  to  determine  the  local  net  address  for  the 
destination  host.  It  calls  on  the  local  network  inter¬ 
face  for  the  second  network  to  send  the  datagram  to 
that  address. 

If  the  datagram  is  too  large  to  be  sent  through  the 
second  network,  the  IP  module  fragments  it  into 
seve;  J  smaller  datagrams  and  passes  each  one  to  the 
local  net  interface. 

The  local  network  interface  creates  a  local  net¬ 
work  packet  and  encapsulates  the  datagram,  sending 
the  result  to  the  destination  host.  At  the  destination 
host,  the  datagram  is  extracted  from  the  local  net 
pKket  and  passed  to  the  IP  module. 

The  IP  module  determines  that  the  datagram  is  for 
an  internet  user  in  this  host,  if  the  datagram  is  a  frag¬ 
ment.  the  IP  module  collects  all  fragments  of  a  parti¬ 
cular  datagram  and  resuembles  the  complete  original 
datagram.  It  then  passes  the  data  to  the  user  along 
with  the  internei  source  address  and  other  informa¬ 
tion  from  the  internet  header. 

2.2.  AJJiiional  Mechanisms 

In  addition  to  the  basic  a^dresime  and  fragmenta¬ 
tion  functions  described  above.  IP  uses  four  key 
mechanisms  ui  providing  its  service.  Type  o/Scntcr. 
Time  to  Live,  (^ttons.  and  Header  Checksum.  Each 
of  these  is  summarized  here  and  fully  desenbed  in 
Sections  2  and  3. 

The  Type  of  Service  (TOS)  is  used  lo  indicate  the 
quality  of  the  lervKc  desired  -  this  may  be  thought 
of  as  selecting  among  Inieractive.  Bulk,  or  Real  Time, 
for  example  Tlte  type  of  service  is  an  absiract  or 
generalized  sei  of  parameters  whK‘h  chatKietue  tii« 
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service  clioices  provided  in  the  networks  tiiat  make 
up  the  Catenet.  This  type  of  service  infurniation  is 
used  by  gateways  to  select  the  actual  parameters  for 
transmission  througlt  each  individual  network. 

The  Time  to  Live  (TTL)  is  an  indication  of  the 
lifetime  of  a  datagram.  Datagrams  must  not  be 
allowed  to  persist  in  the  ARPA'Catenet  indefinitely. 
This  is  because  reliable  end-to-end  protocols  depend 
on  there  being  an  upper  bound  on  datagram  lifetime, 
especially  old  duplicates  due  to  retransmissions.  The 
time  to  live  con  be  thought  of  as  a  self-destruct  time 
limit. 

The  Options  provide  for  control  functions  useful 
in  some  situations  but  unnecessary  for  the  most 
common  communications.  The  options  include  provi¬ 
sions  for  timestamps,  error  reports,  and  special  rout¬ 
ing. 

The  Header  Gtecksum  provides  a  verification  that 
the  information  used  in  processing  the  daugram  has 
been  transmitted  correctly.  However,  the  data  is  not 
covered  by  tire  checksum,  and  may  contain  errors 
(see  r>ection  2.6).  If  the  header  checksum  fails,  the 
internet  datagram  is  discarded  by  the  entity  which 
detects  the  error. 

2,4.  Reletion  to  Other  Work 

The  current  ARPA  Internet  Protocol  evolved  from 
ideas  suggested  by  Cerf  and  Kahn  [4],  and  from 
contemporaneous  preposais  within  the  International 
Federation  for  Information  Processing  (IFIP)  Tech¬ 
nical  Committee  6.1  (also  known  as  tlie  International 
Network  Working  Group  or  INWC),  in  which  internet 
functions  and  reliable  transport  functions  were  com¬ 
bined  in  a  single  protocol.  Subsequent  development 
of  other  high  level  protocols  (such  as  packet  speech) 
that  needed  internet  services  led  to  splitting  internet 
functions  and  reliable  transport  functions  into  sepa¬ 
rate  protocols  (the  current  IP  and  TCP). 

The  Internet  Protocol  used  in  the  ARPA-Catenet 
is  quite  similar  in  philosophy  to  the  PUP  protocol 
(5)  developed  by  tire  Xerox  Corporation.  The  PUP 
protocol  does  not  include  fragmentation  (leaving  this 
to  each  local  net  to  perform  if  necesury).  but  does 
include  a  third  level  of  addressing  (Ports  witJtin  hosts) 
in  die  internet  packet  header.  IP  and  PUP  share  the 
important  principle  of  having  a  single  common  inter¬ 
net  datagram  protocol  as  a  point  of  convergence  in 
their  protocol  hierarchies.  Both  the  PUP  and  IP 
systems  use  the  encapsulation  technique,  and  a 
scheme  for  “mutual  encapsulation"  has  been  worked 


out  [6].  PUP  and  IP  both  trace  titcir  roots  to  a  joint 
XHROX-DARPA  project  at  Stanford  University.  The 
network  interconnection  approach  used  by  the 
European  Infonnatics  Network  (7J  is  also  quite 
similar. 

Public  packet  switching  networks,  on  the  other 
hand,  have  chosen  to  use  virtual  circuit  (VC)  level  of 
service  as  the  level  of  interconnection,  providing  end- 
to-end  service  as  a  concatenation  of  VCs  through  each 
network.  Since  gateways  must  participate  at  the  VC 
level,  they  are  more  complex  and  costly,  and  the  end- 
to-end  service  may  be  less  efficient  and  less  robust. 
They  axe  also  unable  to  accommodate  “transaction” 
type  users  without  setting  up  a  VC,  although  die 
CCITT  is  currently  considering  adding  a  datagram 
type  of  service.  For  furdier  comparison  of  CCITT  and 
Catenet  approaches  see  (8-12). 

In  summary,  the  ARPA  Internet  Protocol  supports 
delivery  of  datagrams  from  an  internet  source  to  a 
single  internet  destination.  IP  treats  each  datagram  as 
an  independent  entity  unrelated  to  any  odier  data¬ 
gram.  There  are  not  connections  or  logical  circuits 
(virtual  or  otherwise).  There  are  no  acknowledgements 
either  end-to-end  or  hop-by-hop.  There  is  no  error 
control  for  data,  only  a  header  checksum.  There  are 
no  retransmissions.  Tliere  is  minimal  flow  control. 
For  flexibility,  it  is  explicitly  left  to  higlier  level 
protoeds  to  provide  these  functions. 

3.  Main  Features 

The  following  paragraphs  describe  in  some  detail 
die  mechanisms  of  the  IP.  A  summary  of  die  contents 
of  die  IP  header  is  shown  in  Figure  3.  Further 
information  may  be  found  in  the  current  specifica¬ 
tion  (1). 

S.I.  Addressing 

Tlie  IP  provides  a  two  level  addressing  hierarchy. 
Tlie  upper  level  of  die  hierarchy  is  the  network 
number  (8  bits),  and  die  lower  level  is  an  address 
within  diat  network  (24  bits),  and  is  commonly 
called  the  host.  This  second  level  of  the  hierarchical 
address  is  sometimes  called  the  local  address.  Tlie 
details  of  the  local  address  are  dependent  on  the 
particular  network. 

Tlie  local  address  siiould  allow  a  single  physical 
host  to  act  as  several  logically  distinct  internet  hosts. 
That  is.  there  siiould  be  mapping  between  internet 
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Fig.  3.  INTERNET  Protocol  Header. 


host  addresses  and  nctwork/host  interfaces  Utat 
allows  several  internet  addresses  to  correspond  to  one 
physical  interface.  It  should  also  be  possible  for 
several  interfaces  to  accept  or  emit  datagrams  for  the 
same  internet  address. 

3.2.  Protocol  Number 

The  Protocol  Number  indicates  the  next  level 
protocol  used  in  the  data  portion  of  tlie  datagram. 
Tliis  allows  the  internet  module  to  demultiplex  the 
incoming  datagrams  to  higher  level  protocol  modules 
for  furtlier  prtKCSsing.  Hence,  the  protocol  number 
indicates  the  format  for  parsing  the  rest  of  the  data¬ 
gram.  Note  that  tliere  is  only  one  protocol  number 
rather  titan  a  source  protocol  and  a  destination  proto¬ 
col  because,  higher  level  protocol  modules  exchange 
datagrams  with  each  oUter  using  tlie  same  protocol. 
For  example,  two  TCP  modules  exchange  TCP  seg- 
ntents  via  datagrams  marked  "TCP”  in  the  protocol 
number. 

One  particular  protocol  number  designates  a  multi¬ 
plexing  protocol  which  allows  several  independent 
data  blocks  from  possibly  different  higher  level  proto¬ 
col  modules  to  be  aggregrated  together  into  one  data¬ 
gram  for  transmission  [!3|. 


3.3.  Fragmentation  and  Reassembly 

The  IP  provides  infomiation  to  allow  datagrams  to 
be  fragmented  for  passage  through  networks  with 
small  packet  size  limits  and  to  be  reassembled  at  the 
destination.  The  necessary  information  includes  an 
identification  of  the  fragments  tliat  belong  to  the 
same  datagram  and  the  position  of  each  fragment 
within  the  datagram. 

The  Identijication  (ID)  field  is  used  together  with 
the  source  and  destination  address,  and  the  protocol 
number,  to  identify  datagram  fragments  to  be 
assembled  together.  The  More  Fragments  flag  (MF) 
is  set  if  the  datagram  is  not  the  last  fragment.  The 
Fragment  Offset  (FO)  identifies  the  fragment  loca¬ 
tion.  relative  to  the  beginning  of  the  original  unfrag¬ 
mented  datagram.  These  offsets  are  counted  in  units 
of  8  octets.  Hence,  if  a  datagram  is  fragmented,  its 
data  portion  must  be  broken  on  8  octet  boundaries. 
Tliis  convention  Is  designed  so  than  an  unfragmented 
datagram  has  all  zero  fragmentation  information 
(MF  =  0,  FO  =  0). 

If  the  Don't  Fragment  flag  (DF)  is  set.  then  inter¬ 
net  fragmentation  of  this  datagram  is  not  permitted, 
although  tliis  may  force  it  to  be  discarded  at  a  gate¬ 
way  to  a  small  packet  network.  DF  can  be  used  to 
prohibit  fragmentation  in  cases  where  the  receiving 
host  does  not  wish  to  reassemble  internet  fragments. 
It  is  also  possible  tliat  a  small  packet  network  could 
use  network  specific  fragmentation  and  reassembly 
without  the  knowledge  or  involvement  of  the  IP 
modules  (14). 

If  a  datagram  is  too  large  to  be  forwarded  througli 
any  net,  the  entrance  gateway  breaks  it  into  as  many 
fragments  as  are  necessary  to  fit  within  that  net's 
packet  size  limit.  Figure  4  shows  a  large  datagram  of 
452  octets  being  fiagmented  into  two  smaller  frag¬ 
ments  (only  the  header  fields  relevant  to  fragmenta¬ 
tion  are  given).  Subsequent  gateways  may  break  the 
fragments  into  even  smaller  fragments  if  necessary 
using  the  same  procedure. 

Datagrams  arriving  at  the  destination  IP  are  easily 
recognizable  as  fragments  if  either  MF  or  FO  is  non¬ 
zero.  Fragments  from  the  same  original  datagram  are 
identified  by  having  identical  ID  fields  (for  a  parti¬ 
cular  source,  destination,  and  protocol  number). 
Fragments  arc  queued  until  the  original  datagram  can 
be  fully  reassembled.  Reassembly  may  be  accom¬ 
plished  by  placing  the  data  from  each  fragment  in  a 
buffer  at  the  position  indicated  by  FO.  Using  the 
header  information  from  the  first  fragment,  the  reas- 
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sembled  diugram  is  processed  further  just  as  if  it  had 
been  received  intact.  If  the  time  to  live  on  any  frag¬ 
ment  expires  during  reassembly,  the  partially 
assembled  datagram  is  discarded,  and  an  error  data¬ 
gram  is  sent  to  the  source. 

A  convention  hu  been  established  in  the  current 
ARPA-Catenet  that  no  datagrams  larger  that  576 
octets  will  be  sent,  and  that  all  receivers  will  be 
prepared  to  receive  a  reassemble  datagrams  up  to  this 
length  (unless  specifically  arranged  otherwise).  This 
number  is  chosen  to  allow  a  data  block  of  512  octets 
and  a  reasonable  number  of  header  octets  for  several 
protocol  levels  to  be  transmitted  in  one  datagram. 
Note  that  the  IP  header  is  repeated  in  each  fragment. 
Hence,  the  minimum  maximum  packet  size  for  any 
network  in  the  Catenet  is  20  header  octets  plus  8  data 
otUeu  Of  28  octets  total. 

The  internet  fragmentation  procedure  allows  the 
fragmenu  to  be  treated  u  independent  datagrams  the 
rest  of  the  way  to  their  destination  (even  taking 
different  routes),  with  reassembly  occurring  only  at 
the  destination. 

There  is  a  need  to  uniquely  identify  the  fragments 
of  a  piriiculaf  daiigram.  Hence  the  sender  must 
choose  the  identifleation  Held  to  be  unique  for  each 
source/destination  pair  and  protocol  number  for  the 
time  the  datagram  (or  any  fragment  of  it)  could  exist 
in  the  internet.  Since  the  ID  field  allows  65436 


different  values,  some  host  may  be  able  to  simply  use 
unique  identifiers  independent  of  destination. 

It  is  beneficial  for  some  higher  level  protocols  to 
choose  the  identification  field.  For  example,  TCP 
protocol  modules  may  retransmit  an  identical  TCP 
segment,  and  the  probability  for  correct  reception 
would  be  enhanced  if  the  retransmission  carried  the 
same  identifier  as  the  original  transmission  since  frag¬ 
ments  of  either  datagram  could  be  used  to  construct 
a  correct  TCP  segment.  Note  that  a  retransmission 
might  be  routed  via  a  different  set  of  networks  and 
gateways  and  also  may  be  fragmented  into  a  different 
number  of  different  sized  fragments.  The  fragmen¬ 
tation  information  permits  reassembly  from  frag¬ 
menu  from  either  copy  of  the  datagram. 

3.4.  Type  of  Service 

The  Type  of  Service  (TOS)  provides  a  network 
independent  indication  of  the  quality  of  service 
desired.  These  parameters  are  to  be  used  to  guide  the 
selection  of  the  actual  service  parameters  when 
transmitting  a  datagram  through  a  particular  network. 
Some  networks  offer  several  piecedence  levels  of 
service.  Another  choice  involves  a  low^lelay  vs.  high- 
reliability  trade  off.  Typically  networks  invoke  more 
complex  (and  delay  producing)  mechanisms  as  the 
need  for  reliability  increases.  A  few  networks  offer 
a  stream  service,  whereby  one  can  achieve  a 
“smoother"  service  at  some  cost.  Typically  this 
invdves  the  reservation  of  resources  within  the  net¬ 
work. 

The  abstract  service  quality  parameters  provided 
by  IP  are: 

Precedence:  Indicates  the  importance  of  this  data¬ 
gram. 

Stream  or  Datagram:  indicates  ii  there  will  be  other 
datagrams  from  this  source  to  this  destination  at 
regular  frequent  intervals  justifying  the  maintenance 
of  stream  processing  information. 

Reliability:  A  measure  of  the  level  of  effort  desired  to 
ensure  delivery  of  this  datagram. 

Speed:  A  meuure  of  the  importance  of  prompt 
delivery  of  this  datagram. 

Speed  over  Reliability:  Indicates  the  relative 
importance  of  speed  and  reliability  when  a  confiici 
arises  in  achieving  both. 

S.5.  Time  to  Live 

The  Time  to  Live  (TTL)  indicates  the  maximum 
time  the  datagram  is  allowed  to  exist  in  the  Catenet. 
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As  a  datagram  moves  through  the  Catenet  the  TTLis 
decremented.  If  die  TTL  reaches  zero  the  datagram 
sliould  be  discarded.  The  intention  is  to  cause  long 
delayed  or  undeliverablc  datagrams  to  be  discarded. 
Guaranteeing  a  maximum  lifetime  for  datagrams  is 
important  for  the  correct  functioning  of  some  higlter 
level  protocols  such  as  TCP,  and  to  protect  the 
Catenet  resources. 

This  field  should  be  decreased  at  each  point  that 
die  internet  header  is  processed  to  reflect  the  time 
spent  processing  the  datagram.  Even  if  no  informa¬ 
tion  is  available  on  the  time  actually  spent,  the  field 
sliould  be  decremented  by  1 .  Tlie  time  is  measured  in 
units  of  seconds,  and  the  maximum  TTL  is  255 
seconds. 

S.6.  Oiecksum 

Tlie  IP  provides  a  checksum  on  the  header  only. 
Since  some  header  fields  may  change  (e.g.,  TTL,  MF. 
FO),  this  is  recomputed  and  verified  at  each  point 
that  the  internet  header  is  processed.  This  is  a  hop-by- 
hop  checksum. 

This  checksum  at  the  internet  level  is  intended  to 
protect  die  internet  header  fields  from  transmission 
errors.  If  die  internet  header  contained  undetected 
errors,  misrouting  and  odier  unanticipated  behavior 
could  result.  There  may  be  applications  in  which  it  is 
desirable  to  receive  data  even  thougli  there  are  a  few 
bit  errors.  If  the  IP  enforced  a  data  checksum  and 
discarded  datagrams  with  data  ichecksum  failures  such 
applications  would  be  restricted  unnecessarily. 

The  checksum  is  computed  as  the  16  bit  one’s 
complement  of  the  one's  complement  sum  of  all  16 
bit  words  in  the  header.  For  purposes  of  computing 
the  checksum,  the  value  of  the  checksum  field  is  zero. 
Tliis  checksum  is  simple  to  compute  and  has  been 
adequately  reliable  for  usage  to  date,  but  it  is  provi¬ 
sional  and  may  be  replaced  by  a  CRC  procedure, 
depending  on  furtlicr  experience. 


The  Total  Length  (TL)  is  the  length  of  the  data¬ 
gram,  including  internet  header  and  data.  There  are 
several  protocol  options,  some  of  which  are  discussed 
in  the  next  section. 


4.  Additional  Features 

The  following  optional  mechanisms  are  available 
in  the  IP  for  use  when  needed. 

4.1.  Source  Routing 

The  Source  Route  option  provides  a  means  for 
the  source  of  a  datagram  to  supply  routing  informa¬ 
tion  to  be  used  by  tlie  gateways  in  forwarding  the 
datagram  to  the  destination. 

As  described  above,  routing  at  each  gateway  is 
based  on  the  internet  address  in  the  destination  field 
of  the  datagram  header.  If  the  source  routing  option 
is  used,  a  series  of  additional  internet  addresses  will 
be  present  in  tlie  option  field.  Wlien  the  address  in 
tlie  destination  field  has  been  reached  and  the  source 
route  is  not  empty,  the  next  address  from  the  source 
route  becomes  the  new  destination  (and  is  deleted 
from  the  source  route  list). 


Hou 


3. 7.  Header  Format  Sou'c*  nouiwg 


In  addition  to  the  main  features  discussed  above, 
the  IP  includes  the  following  items  in  the  datagram  'i 

header.  * 

A  Version  Number  (VER)  which  indicates  tlie 
version  of  the  IP  in  use,  and  hence  the  format  of  the  iM.-to 

.  .  '"CM  * 

internet  header.  to  i 


The  Internet  Header  Length  (IHL)  is  the  length  of 
tiie  internet  header  and  tlius  points  to  the  beginning 
of  tlie  data. 
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Fig.  5.  Source  Routing  E.xample. 
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Thus,  the  source  specifies  a  series  of  points  the 
datagram  must  pass  throu^  on  the  way  to  its  final 
destination.  Normal  internet  routing  is  used  to  reach 
eacli  of  these  points  in  turn,  and  the  datagram  may 
pass  through  a  number  of  intermediate  points 
between  the  specified  addresses.  Source  routing  may 
be  used  to  specify  routes  to  networks  that  are  not 
known  to  the  full  internet  system. 

In  Figure  5  an  example  of  source  routing  is  shown. 
Here  host  A  is  sending  a  datagram  to  host  E.  The 
normal  routing  would  most  likely  be  through  tfie 
gateway  C.  We  assume  the  user  at  host  A  would 
prefer  in  this  case  to  have  this  datagram  routed 
through  gateways  B  and  D.  The  Figure  shows  the 
address  information  at  each  step  along  the  route. 

4.2.  Return  (or  Record)  Route 

The  Return  Route  option  provides  a  means  to 
record  the  route  taken  by  a  datagram.  A  return  route 
is  composed  of  a  series  of  internet  addresses.  When  an 
IP  module  routes  a  daugram  and  the  return  route 
option  is  present,  the  gateway  inserts  its  own  inter¬ 
net  address  (in  the  environment  of  the  next  destina¬ 
tion)  into  the  return  route  option  data. 

4.3.  Error  Report 

The  Error  Report  option  is  used  to  report  an  error 
detected  in  proceuing  a  daugram  to  the  source.  A 
code  indicates  the  type  of  error  detected,  and  the  ID 
is  copied  from  the  datagram  in  error,  and  additional 
octets  of  error  information  may  be  present  depending 
on  the  error  code.  If  a  datagram  consisting  only  of 
an  error  report  option  is  found  to  be  in  error  or  must 
be  discarded,  no  error  report  is  sent. 

Error  codes  are  defined  to  report  the  following 
conditions:  (0)  No  reason  given,  (I )  Not  Accepted  - 
no  program  at  the  destination  will  accept  the  data¬ 
gram,  (2)  Fragmentation  Problem  -  the  datagram 
cannot  be  delivered  witliout  fragmenting  and  the  DF 
flag  is  set,  (3)  Reassembly  Problem  -  the  datagram 
cannot  be  reassembled  because  there  are  missing  frag¬ 
ments  and  the  time  to  live  has  expired,  and  (4)  Gate¬ 
way  Congestion  -  lite  datagram  was  discarded  to 
relieve  congestion. 

5.  Gateway  Functions 

Tliis  section  summarizes  the  tasks  performed  by  a 
gatfway;  which  are.  interfacing  to  the  local  networks. 


Fig.  6.  Gateway. 


and  performing  the  IP  functions. 

The  actual  interconnection  of  networks  is 
perfonned  by  gateways  which  are  computers  con¬ 
nected  as  hosts  on  several  networks  (see  Figure  6). 
Messages  are  communicated  across  networks  by  using 
the  protocols  and  conventions  of  the  individual  net¬ 
works.  Wliilc  traversing  each  network  tlie  IP  datagram 
is  encapsulated  within  the  local  network  protocols. 
At  the  gateway  the  IP  datagram  is  decapsulated  and 
examined  by  the  gateway  to  determine  how  to  route 
tliis  datagram,  and  what  local  network  options  to  use, 
if  any.  Tlie  gateway  handles  issues  of  routing,  frag¬ 
mentation  (if  tlie  local  network  cannot  handle  regular 
size  datagrams),  error  reporting  and  control,  and 
interfacing  to  local  networks. 

The  essential  purpose  of  a  gateway  is  to  forward 
each  datagram  toward  its  destination.  Tlie  key  deci¬ 
sion  a  gateway  must  make  is  tJie  routing  decision. 
When  a  gateway  receives  a  datagram  it  must  use  the 
destination  address  in  the  IP  header  along  with  rout¬ 
ing  information  stored  in  tlie  gateway  to  dcierniine 
where  to  send  the  datagram. 

Tlie  routing  infonnation  stored  in  the  gateway 
may  be  relatively  static  (changed  only  by  manual 
intervention)  or  dynamic  (changed  automatically  i. 
Both  cases  are  allowed  in  the  ARPA-Catenet  sysieni. 
The  discussion  of  the  techniques  for  dynamically 
updating  the  routing  information  are  described  by 
Strazisar  (IS). 

Another  important  task  of  a  gateway  is  to  encap¬ 
sulate  datagrams  fot  transmission  ihroucli  tlie  next 
network,  using  that  network's  existing  message  trans- 
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fer  protocol.  This  involves  adding  an  appropriate 
message  header  (and  perhaps  trailer),  to  the  datagram. 
The  gateway  must  interpret  the  type  of  service  field 
of  the  IP  header  to  select  tlie  appropriate  service  in 
tire  next  network. 

Tire  gateway  decreases  tlie  TTL  to  account  for  tire 
time  elapsed  since  tire  TTL  was  last  adjusted.  This  is 
an  estimate  of  the  time  spent  in  transmission  and 
processing.  If  this  reduces  the  TTL  to  zero  the  gate¬ 
way  discards  the  datagram. 

If  the  datagram  is  larger  than  the  maximum  packet 
size  of  the  next  network,  the  gateway  may  fragment 
it  into  pieces  tlrat  will  be  sent  separately. 

If  the  gateway  must  discard  a  datagram  due  to 
congestion  or  errors  in  processing  the  datagram  (such 
as  an  unknown  or  currently  unreachable  address),  it 
sends  an  error  report  datagram  to  the  source  of  the 
discarded  datagram. 

Of  course,  the  gateway  verifies  the  IP  header 
checksum  on  every  datagram  it  receives  before  pro¬ 
cessing  it.  If  the  check  fails  the  datagram  is  discarded 
with  no  notification  to  the  source  or  adjacent  gate¬ 
way.  Since  some  of  the  IP  header  information  is 
changed  during  gateway  processing  (e.g.  TTL),  the 
gateway  computes  a  new  IP  header  checksum  before 
sending  it  on. 

Each  datagram  can  be  processed  completely 
independently  of  other  datagrams.  The  provision  of 
error  recovery,  sequencing,  or  flow  control  functions 
are  left  for  end-to-end  protocols,  and  the  gateway 
does  not  maintain  any  status  information  or  dedicate 
any  resources  for  individual  virtual  circuits.  Indeed, 
the  gateway  is  unaware  of  any  details  of  the  higlter 
protocol  levels. 

6.  Design  Decisions 

The  key  decision  in  the  design  of  the  ARPA  Inter¬ 
net  Protocol  is  tlie  choice  of  a  datagram  basis  rather 
tlian  a  virtual  circuit  basis.  Using  datagrams  as  the 
basis  of  communication  in  tlie  Catenet  permits  the 
use  of  simpler  gateways  since  they  are  not  required  to 
maintain  state  information  about  the  individual 
virtual  circuits,  and  allows  the  end-to-end  communi¬ 
cation  to  continue  via  alternate  routing  if  a  gateway 
fails. 

Using  datagrams  as  the  basic  communication  ser¬ 
vice  allows  the  construction  of  virtual  circuit  style 
end-to<nd  services  (e.g.,  TCP),  and  other  services.  In 
the  DARPA  research  program  tliere  are  needs  for 
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other  styles  of  communication  service.  For  example, 
the  packet  speech  requires  a  service  which  provides 
minimal  delay  even  at  the  cost  of  a  few  dropped 
messages.  Such  a  service  can  be  built  on  a  datagram 
base,  but  not  on  a  virtual  circuit  base.  For  more  detail 
on  tile  tradeoff  between  a  datagram  base  and  a  virtual 
circuit  base  for  communications  see  references 
18-121. 

This  choice  of  a  datagram  base  for  the  operation 
of  the  Catenet  results  in  the  separation  of  the  internet 
protocol  from  the  end-to-end  protocols  in  general  and 
TCP  in  particular.  The  early  proposals  for  TCP  did 
not  focus  clearly  on  the  responsibilities  of  tlie  gate¬ 
ways  and  did  not  allow  for  alternate  styles  of  com¬ 
munication  service.  Once  these  needs  w:;re  apparent 
tJie  protocol  functions  were  separated  into  distinct 
layers. 

The  decision  to  use  the  encapsuiation/decapsuia- 
tion  technique  to  send  the  IP  datagrams  througli  local 
nets  was  made  to  maximize  individual  networks' 
autonomy,  and  to  avoid  the  need  for  modifications  of 
individua'  networks  (particularly  in  the  area  of  rout¬ 
ing)  to  support  internet  traffic  [10]. 

The  decision  to  fragment  datagrams  in  gateways  as 
they  pass  from  a  large  packet  network  into  a  small 
packet  network,  but  not  reassemble  tlie  fragments 
until  they  reach  the  destination  Inst,  allows  simpler 
gateways  and  minimizes  tlie  delay  in  the  Catenet.  The 
alternate  approach  of  reassembly  in  the  next  gateway 
is  explored  in  reference  [14). 

Perhaps  the  most  difficult  design  decision  was  the 
choice  of  Uie  address  size  and  structure.  Tlie  size  of 
the  address  field  is  a  compromise  that  allows  enougli 
addresses  for  the  anticipated  growth  of  the  Catenet 
yet  is  not  an  excessive  overhead  burden.  The  structur¬ 
ing  of  the  address  into  network  and  host  fields  allows 
the  gateways  to  piocess  datagrams  destined  for 
distant  networks  on  the  basis  of  just  the  network 
field.  This  field  separation  also  rclleets  an  administra¬ 
tive  delegation  of  the  address  assignment  function. 

In  addition  to  the  address,  IP  carries  additional 
address  or  multiplexing  information  in  the  protocol 
field.  This  indicates  which  next  level  protocol  should 
be  used  to  interpret  this  datagram.  Most  of  the  higliei 
level  protocols  have  further  multiplexing  information 
called  pons  in  tJieir  headers.  The  IP  approach  to 
addressing  may  be  characterized  as  hierarchical  |  lOj. 

An  option  in  IP  supports  the  concept  of  source 
louting.  This  means  a  source  may  specify  a  series  of 
addresses  which  arc  usee  in  luin  until  the  ultimaie 
dcstinaiion  is  reached  (lOj.  The  decision  lo  include 
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this  feature  was  motivated  by  the  realization  that 
many  small  networks  may  be  interconnected  to  the 
Catenet  via  ad  hoc  arrangements,  and  destinations  in 
such  networks  (or  such  networks  themselves)  may  be 
unknown  to  gateways  in  the  general  Catenet. 

IP  uses  a  Time  To  Live  which  is  decremented  by 
each  gateway  by  at  least  one  unit  (more  if  the  data* 
gram  is  delayed  in  the  gateway  for  a  substantial  time). 
Other  protocols  use  a  hop  count  which  is  incre¬ 
mented  by  each  gateway  [S  j.  The  practical  difference 
is  small,  thou^  the  time  to  live  approach  remains 
effective  as  the  size  of  the  network  changes,  and 
allows  the  source  to  specify  a  maximum  life  for  the 
datagram. 


7.  Research  lawas 

7.1.  Multiple  Addresses 

There  are  several  issues  related  to  more  flexible 
addressing  that  the  current  IP  does  not  deal  with.  One 
case  is  a  host  with  two  (or  more)  internet  addresses, 
either  on  one  network  or  even  on  different  networks. 
Sometimes  this  serves  to  distinguish  between  logically 
separate  hosts,  but  in  other  ases  it  is  desirable  to 
consider  both  addresses  as  the  **same  place"  as  far  as 
higher  level  protocols  are  concerned.  It  is  not  clear 
how  a  gateway  could  know  when  or  how  to  route 
messages  sent  to  one  address  to  another  address  (e  4. 
if  the  first  address  was  unreachable).  A  particularly 
difficult  example  of  this  problem  is  a  mobile  packet 
radio  which  moves  from  one  network  to  another 
while  trying  to  maintain  unbroken  communication. 

7.2.  Local  Networks 

A  second  issue  is  the  addressing  of  local  networks. 
There  will  soon  be  a  large  number  of  local  netwoiks 
(e.g.,  networks  within  one  building  or  on  a  campus) 
wishing  to  use  the  ARPA-Catenei  for  long  distance 
interconnection.  It  seems  unreasonable  that  every  one 
of  these  should  have  the  same  sutus  as  a  nationwide 
network,  with  all  gateways  responsible  for  maintain¬ 
ing  routing  information  about  them.  It  may  be 
preferable  to  introduce  another  level  in  the  addressing 
hierarchy,  or  to  combine  a  gateway  plus  internal 
address  for  such  nets  in  the  local  address  field  of  IP 
addresses  (16). 


7.3.  Multiple  Destinations 

Another  addressing  issue  is  provision  of  a  capabil¬ 
ity  to  send  datagrams  to  a  number  of  destinations  at 
once.  Broadcast  to  all  is,  of  course,  the  ultimate 
multi-destination,  but  “to  all"  is  easier  to  handle  .'  en 
“to  some."  This  capability  is  inherent  in  Ute  techno¬ 
logy  of  some  networks  (e.g.  satellite,  ring,  and  Ether¬ 
nets)  but  there  is  no  provision  in  the  current  IP  for 
such  multidestination  addressing.  These  is  work 
underway  in  the  ARPA  community  on  an  internet¬ 
work  digital  packet  speecli  conferencing  experiment. 
A  protocol  called  ST  developed  for  that  experiment 
does  contain  a  multidestination  capability  [17|. 

7.4.  NantintlAddressingl Routing 

The  mapping  of  character  string  names  that  are 
convenient  for  people  into  internet  addresses  is  often 
a  problem.  This  can  be  eased  by  the  provision  of  a 
"directory  assistance"  service  or  name  server  (18).  A 
name  server  is  a  service  with  a  table  of  name/address 
correspondences.  When  the  name  server  is  sent  a 
query  about  a  name  it  responds  with  the  name  and 
corresponding  address(es).  Directory  services  can  be 
provided  in  a  centralized  and/or  distributed  fashion. 
For  a  further  diKussion  of  the  roles  of  names, 
addresses,  and  routes  see  ( 1 9 1 . 

7.5.  Congestion  Control 

Congestion  control  is  a  problem  for  any  network. 
The  pteways  may  be  viewed  as  nodes  of  the  Catenet, 
much  u  IMrt  are  the  nodes  of  the  ARPANET.  As 
internet  traffic  increases,  pteways  may  become  over¬ 
loaded.  even  while  the  individual  networks  con¬ 
necting  them  are  enforcing  their  own  congestion 
controls.  Thus  there  may  be  a  need  for  an  internet 
conpstion  control  mechanism  which  is  effective  with 
the  datapam  mode  of  operation  in  tJte  Catenet. 
Several  methods  such  as  isarithmic  control,  buffer 
categories,  and  "choke"  packets  (20|  have  been  pro¬ 
posed  for  sucli  environments.  TIte  ARPA  gateways 
implement  a  simple  strategy  of  notifying  the  source 
when  a  packet  must  be  discarded  due  to  congestion. 

7.6.  Monitoring  and  Adminstrative  Control 

Accounting  is  another  basic  internetworking 
requirement.  Traffic  statistics  are  useful  for  monitor¬ 
ing  and  control  purposes,  and  are  easily  collected  by 
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the  gateways  either  on  a  net-to-net  basis,  or  with 
more  detail  by  internet  source/destination  pairs. 
Volume  of  packets  and/or  bits  can  be  collected  by  a 
set  of  counters,  and  periodically  dumped  to  a  Catenet 
monitoring  and  accounting  center.  A  gateway  moni¬ 
toring  and  control  center  is  now  operating  to  coordi¬ 
nate  tlie  collection  of  tliese  statistics  [21]. 


8.  Conclusions 

The  A  RPA  Internet  Protocol  provides  a  common 
base  for  supporting  higlier  level  protocols  in  a  net¬ 
work  independent  multi-network  environment.  The 
datagram  basis  of  the  internet  protocol  has  allowed 
the  flexible  evolution  of  a  variety  of  application 
specific  higher  level  protocols  while  allowing  simple 
pteways  to  interconnect  networks.  Tlie  principle  of 
encapsulation  for  transmission  througli  individual 
networks  is  essential  for  the  provision  of  internet 
service  over  a  variety  of  networks  without  requiring 
changes  to  each  networks'  internal  operation. 

As  of  August  1980,  IP  is  implemented  in  12  gate¬ 
ways  interconnecting  10  networks,  including  packet 
radio,  satellite,  local  nets,  and  the  original  ARPA¬ 
NET.  Gateways  are  typically  PDP  11/40  or  11/03 
processors  with  limited  memory.  High  level  protocols 
including  TCP,  terminal  access  (Telnet),  and  file 
transfer  (FTP)  are  in  use  above  IP.  Transaction 
oriented  services  such  as  directory  assistance  (Name 
Server)  are  also  in  use.  Other  applications  are  under 
development. 
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Abitraet 

Tha  increaaing  raquirescnt  for  data  cooBuni* 
cation!  in  the  nilitary  environaent  and  the  hetero* 
geneou!  nature  of  the  network  technologies  and  pro* 
tocol!  involved  are  highlighted.  The  aain  section 
of  Che  paper  discusses  how  the  design  of  a  ailitary 
internet  architecture  is  influenced  by  the  ailitary 
requireaents  especially  that  of  survivability. 
Comparison  with  the  civilian  ?TT  approach  to  inter¬ 
networking  shows  that  while  there  are  econoaic 
advantages  to  using  civilian  international  stan¬ 
dards  where  possible,  these  standards  do  not 
satisfy  the  ailitary  requiresMnts.  In  particular 
the  strategies  for  routing  in  a  heavily  damaged 
network  environment  and  addressing  hosts  that 
flugrate  froa  one  network  to  another  must  fora  an 
integral  part  of  the  overall  architectural  design. 
This  results  in  gstewsys  whose  routing  tables 
have  8  finer  degree  of  detail  of  Che  internet  to¬ 
pology  than  is  usually  required  but  which  do  not 
contain  connection  oriented  information. 

Finally,  practical  experience  gained  on  the 
ARPA  catenet  system  is  described. 


I.  Introduction 

The  increasing  complexity  and  tempo  of  modem 
warfare  has  rapid ly  created  the  need  for  flexible 
data  conminicacions,  parallel  to  those  associated 
with  the  "information  technology"  growth  in  the 
civilian  environaent.  The  aim  of  this  paper  is 
to  highlight  the  differences  in  emphasis  between 
dats  coanunications  in  the  civilian  and  ailitary 
environments,  snd  te  examine  the  consequence  of 
these  differences.  In  particular,  the  importance 
of  an  overall  conaunications  architecture,  in 
order  to  provide  survivable  and  interoperable 
cosaounications  involving  both  present  and  future 
systems,  cannot  be  evcr.stated. 

Experience  gained  in  connecting  a  prototype 
military  network  to  the  ARFA  cstenet  system  and 
measurements  made  using  internetworking  data  trans¬ 
port  protocols  sre  described.  Enhancements  to  the 
system  to  improve  survivability  and  performance 
are  suggested. 

II.  The  Requirement 

To  a  large  extent,  the  increase  in  the  demand 
for  data  coomjnications  stems  from  the  increasing 


use  of  computers,  microprocessors  and  digital  cir¬ 
cuitry  in  weapons,  sensor,  and  conaand  and  control 
systems.  These  devices  sre  used  for  similar  rea¬ 
sons  to  those  pertaining  in  the  civilian  environ¬ 
ment,  in  that  they  can  perform  well  specified  tasks 
faster,  more  reliably  and  more  cheaply  than  human 
personnel.  However,  in  order  to  accomplish  the 
overall  goal  of  efficient  deploysMtnt  of  military 
resources,  these  geographically  separated  devices 
must  cooBunicste  with  each  other  and  exchange  in¬ 
formation  in  a  hostile  environment.  A  distinctive 
property  of  the  communications  between  these  de¬ 
vices,  is  the  very  "bursty"  or  non-continuous 
nature  of  the  information  transfers,  which  makes 
packet  switching  an  attractive  means  of  providing 
the  conounications.  In  packet  switching,  bandwidth 
is  only  allocated  on  demand,  and  therefore  this 
technique  allows  considerably  more  efficient  shar¬ 
ing  of  coBBunication  resources  than  the  use  of 
dedicated  connunication  links.  A  further  advantage 
of  a  well  designed  network,  is  the  inherent  sur¬ 
vivability  of  communications  that  it  provides. 

This  docs  not  mean  that  networks  in  a  damaged  con¬ 
dition  provide  the  same  quality  of  service  as  in 
their  pristine  condition,  hence  the  necessity  for 
priority  markings  to  indicate  which  data  is  the 
most  important.  However,  we  can  say  that  packet 
switching  is  an  economical  means  of  distributing 
the  cosBBunications  resources  in  such  s  manner  that 
it  is  difficult  for  the  enemy  to  completely  destroy 
comnications  between  users  of  the  network. 

So  far  wc  have  described  a  single  set  of  users 
connected  to  one  network.  However,  there  sre  many 
different  types  of  networks  based  on  different 
technologies  and  providing  different  types  of  ser¬ 
vice.  This  diversity  of  network  types  is  due  to 
the  different  user  requirements  and  environments. 
For  example,  naval  data  coanunications  may  well  be 
provided  by  a  packet  satellite  network  because  of 
the  large  geographical  area  of  coverage  required 
and  the  great  mobility  of  the  hosts  or  users  of 
the  network.  In  the  forward  area  tactics!  environ¬ 
ment,  the  data  covunications  may  well  be  provided 
by  a  frequency  hopping  packet  radio  network,  be¬ 
cause  of  the  extreme  hostility  of  the  electromag¬ 
netic  environment.  Finally,  in  an  underground 
control  centre,  or  on  board  a  single  ship,  the 
coanunications  My  be  provided  by  a  "local  area 
network". 

Besides  these  different  hardware  technologies 
the  grade  of  service  provided  to  the  user  My 
differ.  For  example,  a  network  which  is  primarily 
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detignad  for  traDaporcing  acntor  infonutioB.  say 
well  be  optinizcd  for  providing  BiBinuB  delay  Ib 
the  delivery  of  the  data,  rather  thao  providiog  re¬ 
liability  of  delivery,  because  of  the  pcriahcblc 
Bature  of  the  data.  Thus,  users  who  are  priBarily 
intereated  iB  reliable  delivery  would  have  to  initi¬ 
ate  transport  control  features  ob  an  and-to-cnd 
basis,  to  provide  for  loss  and  Bisordering  of  the 
date  by  the  network. 

There  is  c  requirtBent  for  uaers  ob  the  differ¬ 
ent  natworka  to  coBannicate  with  each  other  H  ].  In 
particular,  the  long  haul  comunicationa  Bay  be  pro¬ 
vided  by  a  cosnon  baarer  network,  which  Bay  inter¬ 
connect  forverd  area  networks  with  local  coaund 
centre  networks.  Also,  with  additional  tasks  and 
new  cepebilities,  there  trill  continue  to  be  new  and 
unknown  data  consunicatioBS  requiraBcnta,  which  will 
have  to  be  integrated  with  existing  systess. 

The  Bain  requireBenta  of  data  communications 
arc  that  they  should  be  secure,  aurviveble  end 
interoperable  |2).  This  paper  concentrates  on  the 
survivebilitr  and  interoperability  iaauea,  and  tha 
reader  is  referred  to  the  references  which  concern 
coBputer  enr";  network  security  |3,4].  However,  it 
is  necessary  to  point  out  that  the  Bora  interoper¬ 
able  tha  ey«ceih£  are,  tha  greeter  the  aecurity 
risks,  bcceuixe  there  era  aiore  avenues  of  attack  on 
the  confidentiality  and  integrity  of  the  data,  by 
a  greater  niatber  of  peracnnel.  In  particular, 

"acceas  controllera''  or  aecmirity  aentinela  in  cri¬ 
tical  geteweys,  which  interconnect  networkt,  SMy 
restrict  access  to  certain  types  of  traffic,  thus 
sacrificing  survivability  and  flexibility  in  the 
interests  of  aecurity.  Survivability  of  eoBOunice- 
tions  has  Bsny  different  saaniogs,  but  in  its  stric¬ 
test  sente  it  iaplies  fully  eutoBStic  routing  around 
dextaged  switching  coaponents  or  links,  and  the  abil¬ 
ity  to  use  alternate  routes,  even  through  other  net¬ 
works,  in  such  a  way  that  data  integrity  is  aain- 
tained  on  an  end-to-end  basis. 

III.  Hassons  for  an  Overall  Architecture 

To  date,  Bost  coaBunicetions  systeas  have  not 
been  designed  with  an  overall  comunications  archi¬ 
tecture  in  Bind.  This  has  resulted  in  great  diffi¬ 
culty  in  providing  interoperability  with  ocher  eya- 
teas.  Because  the  aodulation  end  coding,  address¬ 
ing  and  aessage  representation,  have  often  bean  cov 
bined,  interconnection  with  another  ayste*  has  in¬ 
volved  a  very  expensive  box  between  the  two  systeas. 
The  disadvantages  of  this  approach  erc:- 

1)  Each  interfece  box  is  a  special  'one  off 
design,  which  is  custoB  built  end  therefore  very 
expensive  in  design  tiar  end  procureaent  cost. 

2)  Incvitebly,  in  translating  between  one  sys- 
ten  and  another,  there  will  be  certain  features  and 
services  chat  will  not  have  an  equivalent  in  both 

aystaas. 

3)  Because  of  the  processing  power  required 
to  translate  at  all  protocol  lev^.ls,  the  interface 
unit  will  be  a  large  and  expensive  piece  of  hardware. 
This  has  an  effect  on  survivability,  in  that  because 


the  interface  units  arc  expensive,  the  aininua  will 
be  procured  and  the  survivability  of  the  overall 
coBBunicatioBS  will  be  dcccraincd  by  these  vul- 
ncrcble  interface  units. 

The  problcB  of  deciding  on  the  beat  architec¬ 
ture  for  coeputer  to  coaputer  coxnunicctions,  has 
been  the  subject  of  austained  discussion  over  the 
past  decade.  In  particular,  the  International 
Standards  Organization's  subcoBsittcc  16  has  pro¬ 
duced  a  Bajor  docuaent  in  this  field,  "Reference 
Hodcl  of  Open  Systeas  Interconnection"  |5).  The 
central  thesis  of  this  docuaent  is  that  the  aost 
flexible  architecture  is  a  layered  one,  in  which 
each  layer  has  c  well  specified  function  and  pro¬ 
vides  a  well  specified  service  to  the  layer  above 
it.  In  particular,  any  given  layar  viaws  the 
Icyera  below  it  cs  e  singla  entity.  This  is  analc- 
gous  to  structured  prograaming,  where  the  user  of 
e  procedure  call  is  only  interested  in  how  pere- 
aeters  are  passed  to  and  froa  the  procedure  end  not 
in  the  internal  structure  of  the  procedure.  The 
seven  layer  aodel  is  illustrated  in  figure  1.  Two 
points  about  the  aodel  are  relevant  to  the  discus¬ 
sion  below.  Firstly,  the  fuccticnal  specification 
of  each  layer  is  wore  difficult  to  agree  on,  the 
higher  the  layer,  because  in  these  layers  in  the 
architecture  there  are  aore  choices.  Secondly, 
there  has  as  yet  been  no  ISO  agreed  protocols  for 
iapleacnting  azy  of  the  layers.  The  aodel  itself 
docs  not  preclude  aore  than  one  protocol  iapleacnt- 
ing  a  given  layer  of  the  architecture. 

IV.  Current  State  of  Civilian  Standards 

In  Europe,  with  its  highly  regulated  public 
coaaunications  authorities,  there  has  been  a  very 
active  co-operetion  aaong  various  countries  to 
establish  data  covunicetions  standards  froa  the 
outset.  The  CCITT  (The  International  Telegraph 
end  Telephone  Conaulative  Coaaittee),  which  is  the 
corporate  body  representing  the  telecoMunications 
authorities  of  these  countries,  has  developed 
standard  prorocols,  X25  |6  ),  for  levels  1,2  I  3  of 
the  ISO  reference  aodel.  It  is  iaportant  to  note 
that  in  arriving  at  these  standards,  the  FTTs 
(Public  Telegraph  end  Telephone  authorities)  have 
identified  that  aost  ewstoaers  want  a  connection 
orientated  type  of  aarvice,  ensuring  ordered  and 
reliable  delivery  of  packets.  The  network  reserves 
.he  right,  in  event  of  a  network  error  or  conges¬ 
tion,  to  aend  a  reset  to  both  ends,  indicating  loss 
of  data  integrity.  At  present,  no  figures  are 
available  to  indicate  the  frequency  of  such  events. 
Because  the  aain  public  networks  in  Europe  arc  X25 
networks,  there  has  been  considerable  pressure  on 
coaputer  aanufacturers  to  provide  X2S  hardware  and 
software  products  off  the  shelf.  This  has  led 
aanufacturers  of  private  networks,  in  particular 
local  aree  networks,  to  consider  providing  Z25 
accesaas,  in  order  to  facilitate  connections  to 
existing  aachines  and  operating  systeas.  Thus,  X25 
is  rapidly  becoaing  a  de  facto  international  atan- 
dard  in  Europe. 

Vhat  about  tha  interconnection  of  X25  networks? 
Obviously,  connecting  networks  which  use  the  saae 
access  protocols  and  provide  the  seat  grade  of 
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service,  is  not  so  difficult  e  problea  es  inter'* 
connecting  very  dissioilsr  networks.  Thus»  there 
sre  X  series  protocols,  X75,  X121  t^],  which  en* 
able  pit's  to  provide  connections  between  users  un 
different  X25  networks,  end  elthough  not  ell  X2S 
facilities  ere  svsileble  on  internetwork  connec¬ 
tions,  the  service  offered  is  enslsgous  to  STD 
dialling  of  internetionsl  telephone  cells.  How¬ 
ever,  these  protocols  do  rely  on  the  X25  networks 
themselves,  to  route  the  internet  peckets  to  the 
getewsys.  It  appears  thet  privste  networks  will 
not  be  allowed  to  connect  to  public  networks  via 
X75  gateways,  end  so  geteweys  between  private  and 
public  networks  will  have  to  provide  a  service  be¬ 
tween  two  X25  cells  back-to-back,  and  will  thes 
act  as  a  ataging  post  for  the  user's  decs. 

Protocols  for  the  transport  layer  (layer  4 
of  the  OSI  Reference  model),  ere  not  so  well 
developed  es  for  the  lower  layers.  However,  in 
the  United  Kingdom  e  transpert  protocol  [7  ]  has 
been  defined,  and  implementeticus  above  X25  have 
been  realized.  The  most  not4tVle  feature  of  this 
protocol  is  the  flexible  addressing  structure, 
which  allows  connections  ro  bt  established  acrose 
different  naming/addresrina  dot^ains. 

Before  considering  the  applicability  of 
these  developments  in  the  militer.'  environment, 
it  is  useful  to  consider  some  of  toe  differences 
in  emphasis,  between  civilian  and  military  net¬ 
works,  end  their  usage. 

V.  Comparison  Between  Civilian  and 
Military  Networks  and  their  Usage 

1)  The  usage  of  military  networks  in  time 
of  war  is  very  difficult  to  predict.  Although 
major  exercises  give  some  idea  of  the  user  demand, 
past  experience  has  shown  thet  these  are  slightly 
artificial  and  suy  not  give  a  true  picture.  In 
civilian  networks,  usage  can  generally  be  accu¬ 
rately  predicted  by  extrspolacicg  present  useage 
patterns,  with  economic  and  equipment  sales  fac¬ 
tors  being  taken  into  account. 

2)  The  availability  of  the  full  capacity  of 
a  military  network  may  well  be  degraded  when  it  is 
eost  needed,  because  links  may  be  jammed  and  nodes 
and  gateways  physically  destroyed.  In  the  civi¬ 
lian  environamnt,  there  it  usually  t  very  high 
availability  of  hardware  and  data  links,  with  the 
use  of  standby  power  supplies  arwl  'hot'  tparca  for 
critical  nodes  such  as  gateways. 

3}  In  general,  there  is  a  considerably 
higher  degree  of  mobility  of  both  users  and  net¬ 
works  in  the  military  environment.  In  particular, 
airborne  networks  such  as  JTIDS  (Joint  Tactical 
Information  Oistribucioo  System),  with  users  such 
as  fighter  aircraft,  will  place  acringent  require- 
menis  on  internetwork  connectiona  and  survivabil¬ 
ity.  A  consequence  of  this  will  be  that  the  users 
amy  well  be  completely  unaware  of  the  internet 
topology.  While  mobile  access  to  networks  will 
oavioualy  develop  in  the  civilian  enviroraent .  in 
general  it  constitutes  a  fairly  static  coaamiiy 
of  network*  and  users. 


A)  One  of  the  major  ed vantages  of  geograph- 
icelly  distributed  detebaaea,  which  are  flexibly 
interconnected  with  conBunicuv.iona  links,  is  the 
decrease  in  vulnerability  of  the  overall  ayatem  to 
the  total  failure  of  e  site  (eg  by  physical  destruc¬ 
tion).  Thus,  when  designing  military  networks  it 
is  important  not  to  introduce  an  Achillea  heel  by, 
for  example,  employing  a  centralized  network  control 
centre.  However,  centralized  control  may  well  be 
the  most  convenient  and  cost-effective  solution  in 
civilian  environment. 

5)  Both  civilian  and  military  network  author¬ 
ities  wish  to  provide  secure,  surviveblc,  inter- 
opersble,  end  guaranteed  grades  of  service  to  their 
users.  Tile  queatiwus  mIISC  sz  tc  hov  such  the  user 
is  willing  to  pay  for  these  properties,  and  how  im¬ 
portant  the  properties  ere?  The  question  of  the 
importance  of  the  property,  depends  on  the  threats 
to  the  network,  and  these  ere  obviously  substan¬ 
tially  greater  in  the  military  case.  This  means 
thet  the  solutions  for  military  networks  may  well 
be  more  expensive,  in  terms  of  implementation  aiul 
running  costa,  than  those  for  the  civilian  environ¬ 
ment. 

VI.  Techniques  For  Network  Interconnection 

At  present  there  are  two  main  architectural 
methods  (8)  for  providing  process  to  process  com¬ 
munication  across  dissimilar  networks.  They  are 
referred  to  as  the  ”end-to-end"  end  "hop-by-hop" 
methods,  because  in  the  former,  ell  the  control 
inforaation  relevant  to  a  particular  date  connec¬ 
tion  is  held  only  in  the  source  end  destination 
hosts,  while  in  the  latter,  connection  oriented 
information  is  also  held  in  various  intermediate 
switching  nodes,  called  getewsys. 

The  end-to-end  approach  is  based  on  the  assump¬ 
tion  thet  ell  networks  will  offer  at  least  en  unre¬ 
liable  decagram  service,  ie  if  e  sequence  of  packets 
is  iajecttd  into  the  network  then  the  destination 
will  receive  some  of  them,  possibly  misordcred,  and 
with  possible  duplication.  Any  improvement  on  this 
greds  of  service  will  be  achieved  by  implementing 
end-to-end  procedures  to  perform  reordering,  re¬ 
transmission  of  leases  end  detection  of  duplicetes. 

A  legitimate  criticism  of  this  approach  is  that 
these  upgrading  procedures  sre  acting  across  ell 
the  networks  in  Che  chain,  which  in  the  cese  of 
good  networks  means  chat  there  are  extra  overheeds 
which  involve  needless  cxpcndilurc.  Thus,  in  Che 
hop-by-hop  approach,  the  required  level  of  inter¬ 
net  service  is  provided  by  procedures  impleaenced 
across  each  network.  This  is  obviously  more  expen¬ 
sive  initia?!'*,  in  chat  the  procedures  arc  different 
for  the  diffarent  networks,  but  its  running  costs 
arc  cheaper  because  unnecessary  control  and  re¬ 
transmissions  do  not  occur  across  the  networks  pro¬ 
viding  Che  higher  grade  of  service. 

There  arc  also  two  schools  of  thought  on 
addressing  strategy,  which  are  difficult  to  com¬ 
pletely  separate  out  from  the  ideas  set  out  above. 
The  first  school,  which  hat  to  date  been  associated 
with  the  end-to-end  approach,  is  that  all  networks 
worldwide  should  have  a  unique  network  number 
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allocated  to  it  by  a  global  authority.  Thus,  any 
holt  address  can  be  uniquely  defined  worldvide  by 
concatenating  its  network  number  with  its  host 
number.  The  addressing  of  internet  packets  is 
then  simple.  The  other  school  believes  that  such 
international  agreement  on  address  formats  is  not 
achievable  in  the  near  future,  and  that  there  will 
exist  multiple  naming/addressing  authorities. 

Thus,  the  address  field  will  have  to  consist  of  a 
list  of  addresses  in  different  formats,  which  will 
be  parsed  by  the  gateways  of  the  different  naming 
authorities  as  the  packet  wends  its  way  through 
the  internet  system.  This  second  system  is  con¬ 
siderably  more  flexible  than  the  first,  but  as  we 
shall  see  has  other  consequences  as  well. 

To  date,  operational  systems  of  the  end-to- 
end  variety  have  used  a  flat  addressing  space  and 
the  hop-by-hop  systems  have  used  the  multiple  do¬ 
main  system.  A  schematic  representation  of  the 
protocol  layering  involved,  in  an  internetwork 
connection  across  three  networks,  is  shown  fer 
both  the  hop-by-hop  and  end-to-end  approaches  in 
figure  2.  Th*  hop-by-hop  diagram  clearly  illus¬ 
trates  that  the  tot:*l  service  is  provided  by 
three  concatenated  services,  involving  different 
transport  protocols  on  diffeient  types  of  net¬ 
works.  The  end-to-end  representation  illustrates 
the  singular  nature  of  the  transport  service, 
which  is  independent  of  attributes  of  the  under¬ 
lying  networks.  We  will  now  compare  the  advan¬ 
tages  and  disadvant*9»c  >-t  systems,  in 

the  light  of  operation  in  the  military  environ¬ 
ment  . 

1)  Running  Costs  The  hop-by-hop  approach  has 
the  advantage  over  the  end-to-end  approach  as 
far  as  the  civilian  user  is  concerned,  in  that 
it  is  very  'tariff  conscious  (ie  it  only  uses 
the  minimum  amount  of  transport  protocol  neces¬ 
sary  to  provide  the  required  grade  of  service). 

Nov  as  many  of  the  European  networks  provide  the 
high  reliability  of  a  virtual  call  service,  this 
means  that  hop-by-hop  implementations  of  the  trans¬ 
port  service  for  these  networks  will  involve  mini¬ 
mum  overheads  in  terms  of  extra  bits  to  be  trans¬ 
mitted,  and  therefore  their  running  costs  will  be 
minimal . 

In  the  end-to-end  approach,  every  packet 
carries  a  full  internet  source  and  destination 
address  in  its  header,  so  that  it  can  make  its  own 
way  to  its  destination.  In  the  hop-by-hop  approach 
once  the  call  has  been  set  up,  only  the  destina¬ 
tion  address  for  that  particular  network  has  to  be 
carried,  because  the  gateways  on  route  contain 
addressing  informatiot.  for  further  hops. 

2)  Development  Costs  The  philosophy  of  the  hop- 
by-hop  approach  implies  a  different  protocol  fer 
each  different  type  of  network.  This  is  not  so 
serious  in  the  civilian  environment,  because  of 

the  considerable  influence  of  the  CCITT  atandards 
which  means  that  most  Eorrpea.^  public  and  private 
networks  are  of  the  X'S  variety.  Even  local  net¬ 
works  with  very  high  apeed  interfaces  are  planning 
to  implement  an  X:5  access.  However,  in  the 
military  environment ,  where  ther*  is  a  considerably 
greater  range  of  networks,  this  could  require  the 


development  of  a  number  of  tranaport  protocols. 

3)  Trusting  Tranait  Networks  When  a  user  makes 
a  Bulti-net  connection,  using  the  hop-by-hop 
approach,  it  implies  that  he  trusts  the  level  of 
transport  service  being  offered  by  the  intermediate 
gateways  in  the  internet  route.  Furthermore,  it 
implies  that  he  ia  happy  with  the  reliability  of 
intermediate  gateways  which,  albeit  temporarily, 
take  responsibility  for  hit  data  at  the  termination 
of  each  hop.  Ve  believe  that  this  it  a  state  of 
aftairt  that  ia  considerably  more  acceptable  in  the 
benign  civilian  environment  than  in  the  hostile 
military  one. 

In  the  end-to-end  approach,  only  an  unreliable 
datagram  delivery  service  is  expected  from  Che  set 
of  concatenated  aetworkt ,  and  loss  of  data  in  any 
intermediate  switching  node  or  gateway  will  be  re¬ 
covered  by  a  retrantmiaaion  from  the  source. 
Therefore,  maintaining  the  bit  integrity  of  the 
data  transmission  does  not  rely  on  the  continuing 
correct  operation  of  an  intermediate  node. 

4)  Addressing  Strategy  In  the  multi-domain 
address  strategy,  if  a  user  in  one  domain  wishes  to 
communicate  with  users  in  another  domain,  the  user 
must  know  the  topology  of  the  interconnection  of 
these  domains,  sc  that  he  can  supply  the  informa¬ 
tion  necessary  for  his  data  to  reach  the  destina- 
ti=r.  dow^iri.  This  information  could  be  obtained 
automatically  for  him,  but  it  implies  separate  and 
possibly  different  bilateral  agreements  between 
the  various  domain  authorities. 

In  the  end-to-end  approach  with  a  flat  address¬ 
ing  apace,  each  packet  contains  complete  addressing 
information,  and  ia  free  to  find  the  best  current 
route  across  all  intermediate  networks  (figure  3). 
This  dynamic  internet  routing  has  similar  reiource 
allocation  advantages  to  dynamic  routing  on  single 
networks.  This  flexibility  of  routing  in  the  inter¬ 
net  environment  is  more  important  in  the  context 
of  the  more  rapidly  changing  scenario  of  the  mili¬ 
tary  environment. 

5)  Transport  Control  The  end-to-end  control  is 
certainly  less  flexible  than  the  hop-by-hop  control. 
Timeouts  in  particular,  may  vary  by  an  order  of 
magnitude ,  even  on  the  networks  in  service  today. 
End-to-end  flow  control,  also  requires  more  sophi¬ 
sticated  strategies  than  are  needed  in  the  hop-by¬ 
hop  method . 

6)  Gateway  Complexity  One  of  the  chief  attrac¬ 
tions  of  the  elnd-to-end  approach  with  flat  address¬ 
ing  it  the  conceptual  tieplicity  and  relative  tmall- 
nesa  of  the  gateways  with  respect  to  the  hop-by-hop 
approach.  This  is  because  the  only  modules  that 
vary  from  gateway  to  gateway  are  the  network  access 
modules  that  pertain  to  each  network  (and  these  are 
juat  the  tiodulet  needed  on  all  hosts  attached  to 
that  network).  The  fact  that  no  connection  orien¬ 
ted  information  it  held  in  the  gateway,  greatly 
tieplifies  the  action  that  the  gateway  hat  to  take 
on  receiving  a  packet  and  the  amount  of  buffer 
storage  it  needs.  This  properly  lies  in  well  with 
the  gateway  policy  for  military  networks,  namely 
that  networks  ahculd  be  multiply  connected  by 
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gatcvtys  in  ordtr  to  provide  turviveble  internet* 
vork  cosnunicetions .  Thus*  the  "tiaplicity"  of 
the  getevayt  will  result  in  chespness  end  the  abi¬ 
lity  to  provide  aorc  than  one  gateway  between 
every  pair  of  networks. 

Thus,  although  the  end-to-end  approach  in¬ 
volves  higher  overheads  in  teras  of  packet  headers 
we  believe  that  it  offers  considerably  increased 
survivsbility  in  a  hostile  environsent.  Further-* 
aore*  in  a  situation  in  which  users  and  networks 
are  aobile*  it  is  necessary  for  all  networks  to 
come  under  a  single  naaing/addressing  authority 
(eg  NATO)  if  these  change^  In  topology  are  to  be 
distributed  rapidly  and  efficiently  throughout 
the  internet  systca. 

VII.  The  AKPA  Catenet  Systea 

An  exaaple  of  the  end-to-end  approach  with  a 
flat  address  space*  which  has  been  running  opera¬ 
tionally  for  about  5  years,  is  the  AXFA  catenet 
systca.  This  systca  connects  about  thirty  differ¬ 
ent  networks  including  land-line,  satellite  and 
radio  based  networks,  as  well  as  a  variety  of 
local  area  networks.  The  thinking  and  concepts 
involved  in  the  architecture  of  this  systea  have 
been  fully  described  in  a  nuaber  of  papers  (9*  10]. 

The  protocols  responsible  for  data  transport 
in  this  systca  and  their  hierarchical  relation¬ 
ship  are  shown  in  figure  4. 

1)  •  Internet  Protocol  (IP)  Ill]  This  provides 
for  transaitting  blocks  of  data,  called  datsgraas, 
froa  sources  to  destinations.  Its  aain  pareaeters 
are  source  and  destination  addresses  which  are 
globally  unique,  laplcaentations  of  this  protocol 
exist  in  the  getcways  and  internet  hosts.  The 
datagraas  are  routed  froa  one  internet  aodule  to 
another  through  individual  networks.  In  this 
approach,  datagraas  aay  be  routed  across  networks 
whose  aaxiaua  packet  sise  is  saaller  chan  they  are. 
In  this  case,  a  frag^encation  aodule  breaks  up  the 
packet  into  saaller  packets,  replicating  enough 
inforaation  in  the  headers  to  allow  ressseably  at 
the  destination,  keasscably  does  not  take  place  in 
the  gateways,  because  packets  aay  take  different 
routes  to  their  destinations.  There  are  a  nuaber 
of  options  available  in  the  internet  protocol  and 
these  are  specified  in  the  control  information  of 
the  header.  Thus,  the  internet  header  is  of  vari¬ 
able  length. 

2)  Transmission  Control  Protocol  (TCP)  (12].  TCP 
ir  a  data  transport  protocol  appropriate  to  level 

4  of  the  ISO  reference  model,  and  is  especially 
designed  for  use  on  interconnected  systems  of  net¬ 
works.  TCP  is  a  connection  oriented,  end-to-end 
reliable  protocol,  designed  to  fit  into  a  layered 
hierarchy  of  protocols  which  support  aulti-network 
applications.  It  provides  for  reliable  interpro¬ 
cess  comaunications.  between  pairs  of  processes  in 
host  computers,  attached  to  distinct  but  intercet.— 
neeted  computer  coanunication  networks.  The  TCP 
assumes  it  can  obtain  a  simple,  potentially  unreli¬ 
able,  datagraa  service  froa  the  lower  level  prete- 
coU.  It  fits  into  a  layered  protocol  architecture 


just  above  a  basic  Internet  Protocol,  which  pro¬ 
vides  a  way  for  the  TCP  to  send  and  receive  vari¬ 
able  length  segaents  of  information  enclosed  in 
internet  datsgrsa  envelopes.  In  order  for  the 
TCP  to  provide  a  reliable  logical  circuit  between 
pairs  of  processes,  on  top  of  the  less  reliable 
internet  coamunication  system,  it  perforas  the 
functions  of  basic  data  transfer,  data  acknowledge¬ 
ment,  flow  control  and  multiplexing. 

3)  Gateway  to  Gateway  Protocol  (CCP)  (13  ].  The 
gateway  to  gateway  protocol  is  responsible  both 
for  distributing  routing  information  through  the 
gateways  of  the  catenet  and  for  advising  co«uni- 
cating  hosts  of  routing  changes,  congestion  con¬ 
trol  and  unreachable  destinations.  The  basic 
routing  algorithm,  in  use  today,  is  the  original 
ARPAnet  routing  algorithm.  This  involves  gateways 
celling  their  nearest  neighbours  which  networks 
they  can  reach  and  how  many  gateway  to  gateway 
heps  are  involved  in  the  route.  If  a  gateway  is 
directly  connected  to  a  network,  then  it  is  said 
to  be  sero  hops  to  that  net.  Catewsys  continuously 
monitor  the  stete  of  the  network  access  switch  to 
which  they  are  connected  snd  their  nearest  neigh¬ 
bour  gsteways  to  ensure  that  routes  through  thca 
are  still  available. 

VIII.  Practical  Experience  of  the  ARPA  Catenet 


In  the  autuan  of  1978,  RSU  sec  up  a  collabora¬ 
tive  program  of  research  and  development  in  com¬ 
munications  with  the  Advsneed  Research  Projects 
Agency  of  the  US  Department  of  Defense.  This 
collaborative  program  involved  the  connection  of 
the  PPSK  (Pilot  Packet  Switched  Network),  our  own 
in-house  research  nerv-rk,  to  the  AIPA  catenet 
systea,  and  providing  terminal  and  file  access  froa 
an  internet  host  on  the  PPSN  to  some  of  the  major 
ARPAnet  hosts.  The  first  two  years  of  the  program 
were  allocated  to  the  development  and  iapleaenta- 
tion  of  a  reliable  connection  between  PPSN  and  the 
ARPA  catenet  systea.  We  have  iapicasnted  the  DoO 
standard  Transaission  Control  Protocol,  the  Inter¬ 
net  Protocol  and  the  Cateway -to-Cateway  Protocol 
in  Coral  64.  In  addition,  we  have  made  many 
measurements  on  the  performance  of  the  catenet 
system,  particularly  in  terms  of  round-trip  delays 
as  the  connectivity  and  the  development  of  the 
catenet  has  evolved. 

The  current  co«tf iguration  is  shown  in  figure  i. 
The  RSRE  internet  host  (PDP-11 /23)  contains  the 
standard  internet  protocols  of  Telnet.  TCP  and  IP, 
and  which  run  under  oui  own  virtual  meamry  opera¬ 
ting  system  DOIDS  119  ].  The  link  level  protocol, 

X25  level  2,  is  used  to  interf:iee  to  the  PPSK. 

This  protocol  is  implemented  on  a  air roprocessor 
coanunication  interface  (X25  line  unit)  which  is 
connected  to  PDP-11  hosts  via  e  standard  interface 
til]. 

The  PPSK  is  eennected  to  the  reet  of  the  catenet 
vie  the  RSR£  getewey.  The  gateway  (PDP-11 /2}}  hae 
three  network  interfacee  on  it,  tach  utinf  a  X23 
lina  unit.  They  art  used  to  provida,  1)  acetas  to 
TfS::,  2)  a  ttsc  port  which  can  bt  directly  connected 


23 


3-157 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1985 


to  a  Deasurenent  hoatt  and  3)  an  interface  which 
connects  the  RSRE  gateway  to  a  gateway  at  Univeraity 
College,  London  (UCL)  via  a  9.61t  bita/a  Poat  Office 
line. 


The  UCL  gateway  ia  connected  to  two  other  net- 
worka,  1)  UCL  net  and  2)  Satnet  (ARPA  packet  satel¬ 
lite  network).  The  connection  to  Satnet  ia  via  the 
Goonhilly  SIMP  (Satellite  Interface  Message 
Processor).  Packets  destined  for  Arpanet  are  for¬ 
warded  by  the  Goonhilly  SIMP,  over  the  shared  64k 
bits/s  half  duplex  satellite  channel  to  the  Etas 
SIMP,  and  from  there  they  are  forwarded  on  to  the 
BBN  gateway,  and  hence  into  Arpanet. 

Catenet  Measurements.  Some  of  these  measurements 
were  made  by  echoing  packets  off  the  various  cate¬ 
net  gateways  (figure  5),  and  a  small  but  represen¬ 
tative  sample  are  listed  below.  By  time  stamping 
the  packets  as  they  leave  the  measurement  host  at 
RSRE,  and  then  comparing  the  time  stamps  with  the 
local  time  when  the  packets  return,  having  been 
echoed  off  the  gateways,  the  single  round  trip 
delay  is  measured.  These  delays  not  only  include 
network  transition  times,  but  also  any  internal 
delays  in  the  gateways. 


The  round  trip  delays  from  the  RSRE  measure¬ 
ment  host  to  various  gateways,  for  internet  packets 
containing  6  data  bytes  are:- 

Gateway  Mean  Delay  (secs)  Min/Hax  Delay  (secs) 


RSRE 

0.2 

UCL 

0.35 

BBN 

2.0 

SRI-PRI 

2.5 

0.2 

0.35  -  0.4 
1.5  -  3.8 
1.9  -  3.8 


The  results  for  the  RSRE  and  UCL  gateways  corres¬ 
pond  to  the  theoretical  delays  expected  due  to 
line  speeds.  The  results  for  the  BBK  and  SRI-PRI 
gateways  are  due  to  the  longer  satellite  delays 
and  control  algorithm  of  Satnet. 


Retransmis'iions  in  TCP.  TCP  can  be  used  for  com- 
munTcatlons  over  a  variety  of  different  networks, 
therefore  the  wide  variation  of  round  trip  delays, 
as  shown  above,  means  that  a  fixed  retransmission 
pctiud  rs  uOt  (uitablc.  Since  i—  some  cases  ther^ 
will  be  significant  delays  when  a  TCP  segment  is 
lost,  while  in  others  there  will  be  unnecessary 
retransmissions. 


To  overcome  this  problem  we  have  implemented  a 
dynamic  timeout  algorithm  for  use  in  TCP.  This 
algorithm  measures  the  time  elapsed  between  send¬ 
ing  a  data  octet  with  a  particular  sequence  number, 
and  receiving  an  acknowledgement  that  covers  that 
sequence  number.  Using  that  measured  elapsed  time 
as  the  round  trip  time  (RTT),  vf.  compute  a  smoothed 
roum.  trip  time  (SRTT)  as: 

SRT7  (ALPKA  *  SRTT)  ♦  ((1  -  iJJ»H>,)  *  RTT) 

and  based  on  this,  compute  the  retransmission  time¬ 
out  (RTO)  as: 

RTO  -  min  {BOUND,  BETA  *  SRTT} 
where  BOUND  is  an  upper  bound  on  the  timeout  (eg 


0.9),  and  BETA  is  a  delay  variance  factor  (eg  1.5). 

The  performance  of  this  algorithm  has  shown  to 
be  very  good  and  has  significantly  reduced  the 
number  of  unnecessary  retransmissions. 

IX.  Enhancements  To  The  Catenet  System 


There  are  a  number  of  situations,  peculiar  to 
the  military  context,  which  are  not  catered  for  by 
the  algorithms  presently  used  in  the  catenet.  Be¬ 
fore  discussing  these  and  possible  enhancements  to 
the  catenet  which  would  improve  its  survivability 
in  the  military  environment,  we  must  introduce  the 
concepts  of  "partitioned  networks"  and  "source 
routing". 

A  "partitioned  network"  is  one  that  is  so 
badly  damaged  that  there  exists  no  paths  between 
certain  of  its  switching  nodes.  Typically,  this 
results  in  two  or  more  subsets  or  partitions  of 
nodes,  within  which  communications  are  possible, 
but  which  cannot  communicate  with  each  other.  Hosts 
connected  to  different  partitions  cannot  communi¬ 
cate  in  the  usual  way.  However,  if  this  network 
is  connected  by  more  than  one  gateway  to  the  cate¬ 
net  system  and  there  is  at  least  one  gateway  on 
each  partition,  hosts  could  still  communicate  by 
an  internetwork  path  as  illustrated  in  figure  6. 

The  concepts  of  routing  to  partitioned  networks  are 
concerned  with  automatic  and  efficient  routing  of 
packets  under  the  conditions  mentioned  above. 

The  principle  of  "source  routing"  is  one  of 
providing  some  of  the  routing  intelligence  in  tl.e 
packet  header,  by  providing  not  just  the  destination 
address,  but  also  some  or  all  of  the  intermediate 
node  addresses  through  which  the  packet  has  to  pass. 
This  facility  is  provided  as  an  option  in  the 
present  DoD  Internet  Protocol. 

1)  Changes  to  the  Catenet  Routing  Algorithm.  The 
cstenet  system  as  presently  configured,  permits 
routing  around  damaged  networks  and  gateways.  It 
assumes  that  hosts  know  the  addresses  of  their  local 
gateways,  and  are  prepared  to  poll  these  gateways 
to  determine  their  status,  and  have  procedures  for 
using  alternate  gateways,  if  the  primary  one  ii 
congested  or  inoperative.  Presently,  routing  to  a 
partitioned  network  would  involve  knowing  the  topo¬ 
logy  of  the  catenet  and  inserting  the  routing  in¬ 
formation  in  the  packet  header  in  the  form  of  a 
source  route.  This  is  perfectly  feasibly,  but  in  a 
fast  changing  military  environment  it  would  be 
preferable  if  the  gateways  contained  enough  informa* 
tion  to  perform  automatic  routing  to  hosts  on  par¬ 
titioned  networks. 

If  the  internet  system  of  gatewsys  is  regarded 
as  a  super-datagram  network,  whose  node  to  node 
protocol  is  the  Internet  Protocol,  then  it  would 
seem  reasonable  that  the  internode  routing  be  based 
on  gateway  or  node  identifiers.  The  routing  inform¬ 
ation  distributed  to  gateways  should  permit  routing 
to  a  specific  gateway,  rather  than  to  a  network. 

As  there  may  be  more  gateways  than  networks,  this 
will  involve  the  storage  of  more  information  in  the 
gateways  than  at  present.  However,  if  there  are 
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additional  t*tavcy  nodes  for  providing  survivabil¬ 
ity  it  is  a  waste  of  resources  if  the  inforvation 
is  not  disseminated  and  used  when  most  needed. 

There  are  two  rcacons  for  wishing  to  change 
the  present  catenet  routing  algoritha:- 

(i)  The  present  algorithm  suffers  from  os- 
cillstions  when  certain  link  failures  occur,  be¬ 
cause  it  uses  repeeted  aiinimization  to  compute  the 
shortest  path.  Presently,  this  problem  is  overcome 
by  having  a  narrow  range  of  link  costs. 

(ii)  The  granularity,  or  fineness,  of  the 
information  distributed  by  the  present  algorithm 
which  performs  routing  to  networks,  is  insufficient 
for  automatic  routing  to  partitioned  networks.  This 
is  because  the  routs  into  a  destination  net  via  two 
different  gateways  may  be  wildly  separated,  ae 
illustrated  in  figure  7.  If  the  network  is  parti¬ 
tioned,  we  need  to  specify  the  entry  into  the  net 
rather  than  juet  the  net. 

A  recognized  candidate  for  the  improved  rout¬ 
ing  algorithm  is  a  modification  of  the  Mew  Arpanet 
Routing  Algorithm  [14:1,  which  ie  currently  used  on 
Arpanet.  Using  this  algorithm,  all  the  gateways 
broadcast  information  to  all  other  gateways  using 
a  flooding  technique.  In  particular,  two  types  of 
information  are  disseminated 

(i)  Each  gateway  broadcasts  the  names  of 
the  nets  to  which  it  is  directly  connected. 

(ii)  Each  gateway  broadcasts  the  names  of  its 
neighbours  with  which  it  can  coanunicate. 

From  this  information,  all  gateways  can  deter¬ 
mine  which  networks  are  partitioned,  because  a 
partitioned  nat  will  have  two  or  more  gatways 
attached  to  it  which  are  unable  to  cosounicata. 
Having  implemented  this  algorithm,  there  arc  one  or 
two  additional  techniques  that  arc  nccccsary  for 
dealing  with  routing  to  partitioned  networkc.  The 
main  remaining  problems  arc,  determining  the  parti¬ 
tion  in  which  the  destination  host  is  located,  and 
specifying  this  in  packets  to  be  sent  to  that  host. 
Mow  specifying  the  partition  could  be  accomplished 
by  specifying  the  identifier  of  the  gateway  through 
which  the  partition  cooaunicatas  with  the  rest  of 
the  catenet.  However,  at  present  there  is  no  for¬ 
mat  for  specifying  gateway  identifiers  in  the  inter¬ 
net  hccdcr.  The  determination  of  which  partition 
the  destination  host  is  in,  is  best  done  by  the 
gateway  connected  to  the  source  host's  network. 

This  gateway  will  know  how  many  partitions  the  des¬ 
tination  network  is  divided  into,  and  the  entry 
gateways  to  these  partitions.  When  the  connection 
is  being  set  up,  the  opening  pcckcts  will  be  sent 
to  all  partitions,  and  the  resultant  reply  will 
contain  the  relevant  partition  identifier.  A  minor 
expension  of  the  internet  header  will  be  required 
for  specifying  gateway  identifiers  in  the  internet 
packet  headers. 

2)  Mobile  Hosts  in  the  Military  Environment. 

There  arc  already  a  number  of  requirements  ^or  air¬ 
craft  flying  from  on^  tactical  net  to  cnothcr,  to 
be  able  to  maintcin  comnication  with  a  ground 


based  comsand  and  control  centre  (15  ].  There  has 
been  considerable  discucsion  on  possible  solutions 
to  this  problem  ( 16,17  ].  The  solution  should,  if 
possible  avoid  using  a  centralized  database,  not 
only  because  of  its  vulnerability  but  also  bacaucc 
a  separata  comminication  must  be  succassfully  par- 
formed  with  the  database,  as  a  pre-requisite  for  a 
successful  connection  to  the  mobile  host.  Further¬ 
more,  as  the  host  moves  from  one  net  to  another, 
updates  to  the  database  muct  be  made  in  a  timely 
manner.  Obviously,  a  third  party  has  to  be  in¬ 
volved  if  two  mobila  hosts  wish  to  comnunicatc. 
However,  the  ground  control  centre  is  a  natural 
anchor  for  mobile  cocnunications,  and  if  the  TCP 
connection  idcntifierc  were  divorced  from  physical 
addresses,  the  scheme  below  would  provide  total 
data  integrity  as  the  mobile  host  changed  networks. 

An  interesting  point,  that  is  immediately 
highlighted  when  considering  this  problem,  is  that 
the  unique  identification  of  a  TCP  connection  is 
at  present  tied  down  to  physical  addressee.  He 
believe  that  this  is  undasirsblc,  and  has  lad  to 
the  present  restricted  attempts  at  solving  this 
problem.  He  believe  that  unique  TCP  identifiers 
should  be  exchanged  at  the  start  of  the  connection 
and  thnt  these  be  used  throughout,  so  that  any 
changes  in  the  physical  addresses  can  be  exchanged 
without  closing  tha  connection  (ie  when  the  air¬ 
craft  changes  nets  it  inserts  its  new  address  in 
tha  source  address  field,  this  is  then  used  by  the 
ground  to  continue  the  connection) .  It  is  possible 
that  there  will  be  a  little  hiccup  as  the  change 
over  from  one  net  to  another  occurs,  beceuse  pack- 
ete  may  arrive  out  of  order,  however  retrensmission 
would  take  care  of  this.  It  would  obviously  be  the 
responsibility  of  tha  mobile  host  to  'login*  to  the 
ground  centra  on  entering  a  network,  co  that  a  con¬ 
nection  could  be  opened  up  from  the  ground.  An 
alternative  approach  would  be  to  include  another 
protocol  layar  directly  above  the  TCP  layer.  This 
new  protocol  would  be  responsible  for  opening  and 
closing  TCP  connections  and  maintaining  data  inte¬ 
grity  as  tha  mobile  host  moved  onto  another  net¬ 
work.  The  disedvantege  of  this  approach,  is  the 
necessity  to  transfer  the  mobile  host's  new  sdd- 
ress  on  a  three  way  handshake  basis,  before  the 
host  moved  onto  the  new  network. 

3)  Congestion  Control  in  the  Cetenet.  The  cate- 
net  is  eLentially  s  super  datagram  network,  and 
congestion  control  consists  of  using  all  possible 
routes  to  the  best  sdvantege  and  being  able  to 
offer  a  graceful  degradation  of  service  when  the 
users  demand  exceed  the  network  resources.  It  is 
important  that  fairness  is  exercised  in  providing 
a  service  to  users,  assuming  that  they  are  of  the 
same  priority.  The  above  implies  that  the  cost  of 
a  route  should  change  if  substantial  queues  build 
up  on  it,  so  that  alternate  routes  become  prefer¬ 
able  in  an  SPF  (Shortest  Path  First)  routing  algor¬ 
ithm.  The  change  in  cost  will  be  reflected  in  the 
routing  updates,  and  alternate  less  congested  routes 
will  be  preferred.  This  requires  a  more  realistic 
meesure  of  internet  routing  costs,  than  the  number 
of  gateway  hops  used  st  present.  This  needs  to  be 
implemented  on  the  catenet  for  tealistic  trials. 
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even  though  the  numbere  of  alteroete  routes  it 
very  small.  Having  thus  made  the  best  use  of  the 
internet  resources,  the  only  remaining  action  it  to 
throttle  off  users  when,  by  their  weight  of  nui^ert, 
they  overload  the  system.  This  throttling  mutt  be 
fair,  bearing  in  mind  priorities.  One  aspect  of 
the  fairness  problem  is  that  gateways  handle  pack¬ 
ets  on  an  independent  datagram  basis  and  are  not 
therefore  conscious  of  "greedy"  users  disobeying 
advisory  flow  control  messages.  A  full  solution  of 
this  problem  would  require  s  complex  control  theory 
model  to  be  solved.  This  would  involve  the  know¬ 
ledge  of  the  queuing  sizes  and  delays  on  all  inter¬ 
gateway  links.  The  despatching  of  packets  from  the 
initial  gateway  would  only  occur  when  its  journey 
through  the  system  could  be  undertaken  without  it 
exceeding  a  specified  delay  band. 

X.  Sunnary 

Many  of  the  concepts  presented  in  this  paper 
have  been  widely  discussed  in  the  ARPA  internet 
conuunity.  The  authors  wish  to  thank  their 
colleagues  in  the  ARPA  internet  ronminity  for  many 
discussions  on  the  concepts  presented  in  this  paper. 
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Connecting 
different  types 
of  networks 
with  gateways 


Darpa’s  Internet  connects  more 
than  20  networks  by  gateways, 
which  transmit  datagrams 
and  allow  adaptive  routing. 


ust  as  packet-switching 
technology  matured  and  spread  to  commercial  appli¬ 
cations,  internetworking  technology  is  now  moving 
from  the  research  environment  into  the  commercial 
world.  Gateways  are  being  built  to  interconnect  X.25 
public  packet-switching  networks,  and  many  more  are 
planned  to  link  various  local  networks  such  as  Ethernet. 

One  of  the  original  interconnected  group  of  networks 
is  the  Department  of  Defense  Advanced  Research  Proj¬ 
ect  Agency’s  (Darpa)  Interrtet  System.  It  uses  commu¬ 
nications  processors  as  gateways  to  link  more  than  20 
networks  that  use  diverse  technologies. 

The  Internet  System  has  been  a  focal  point  for  inter¬ 
networking  development,  with  much  of  the  technology 
supplied  by  Bolt  Beranek  and  Newman  (BBN)  of  Cam¬ 
bridge.  Mass.  For  example,  the  Internet  gateway  trans¬ 
mits  information  in  the  form  of  datagrams  and  allows 
different  routing  schemes  to  be  determined  dynamical¬ 
ly  depending  on  the  best  available  path.  The  alternative 
approach  to  the  datagram  model  for  gateways  is  the 
virtual-circuit  approach,  which  determines  and  estab¬ 
lishes  a  route  before  information  is  transmitted.  Each 
scheme  has  advantages  and  disadvantages  related  to 
congestion,  reliability,  and  overhead 

In  general,  gateways  extend  network  users'  abilities 
to  access  remote  machines,  transfer  tiies  between  dif¬ 
ferent  vendors'  computers,  and  send  electronic  mail. 
They  also  provide  a  solution  to  the  problem  of  deciding 
which  of  the  many  networking  methods  is  best  by  al¬ 
lowing  all  of  them  to  be  used,  depending  on  the  appli¬ 
cation.  The  different  types  of  networks  can  then  be 
interconnected  by  gateways,  thus  giving  tite  user  a 
view  of  only  one  large  network  configuration. 

The  fundamental  technology  of  gateways  is  straight¬ 
forward.  For  example,  two  networks  "A"  and  •*B." 
composed  of  hosts,  nodes,  and  lines,  are  linked  by 


connecting  a  communications  processor  that  runs 
internetworking  software  to  each  of  the  networks.  The 
combination  processor  and  software  is  a  gateway. 

Host  A  can  send  a  message  to  host  B  on  network  B 
by  first  sending  the  message  to  the  gateway.  The  gate¬ 
way  then  forwards  the  message  through  network  B  to 
destination  host  B. 

Several  gateways  can  be  used  to  interconnect  a 
number  of  different  networks.  These  multiple  gateways 
provide  redundancy  and  additional  load  capacity. 

The  user  view  of  the  interconnected  networks  is  sim¬ 
plified  if  the  gateways  are  regarded  as  switching  nodes 
and  the  networks  as  lines.  Then  the  entire  configuration 
can  be  viewed  as  a  single  network,  built  from  a  collec¬ 
tion  of  separate  networks. 

Gateways  forward  messages  across  networks  to 
other  gateways  within  an  internetwork  system  just  as 
switching  nodes  forward  messages  across  lines  to  oth¬ 
er  switching  nodes  within  a  single  computer  network. 
However,  to  provide  an  efficient,  reliable  communica¬ 
tions  service,  the  gateways  should  also  provide 
switching  node  functions  such  as  adaptive  routing, 
flow  control,  and  network  monitoring. 

The  tranMtIantie  connection 

There  are  two  approaches  to  internetworking;  the  vir¬ 
tual-circuit  approach  and  the  datagram,  in  the  archi¬ 
tecture  that  the  Internationa!  Consultative  Committee 
for  Telegraphy  and  Telephony  (CCITT)  recommends, 
the  internetwork  switching  nodes  provide  virtual-circuit 
service  between  networks.  To  do  this,  each  switching 
node,  called  an  X.75  gateway,  is  directly  connected 
to  X.75  gateways  on  other  networks.  When  a  call  is 
established  between  two  networks,  virtual  circuits  are 
set  up  between  the  source  host  and  an  X.75  gateway 
on  the  source  network,  between  neighboring  X.75 
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work  architecture  that  allows  networks  with  different 
access  protocols  to  be  interconnected.  The  Internet 
System  differs  in  several  important  ways  from  the 
CCITT  architecture.  For  example,  gateways  are  con¬ 
nected  directly  to  networks  instead  of  being  connected 
to  other  gateways.  In  addition,  traffic  is  sent  across 
the  networks  in  the  form  of  datagrams  instead  of  via 
virtual  circuits  between  the  networks.  And.  most  impor¬ 
tantly.  the  Oarpa  Internet  uses  an  adaptive-routing 
scheme  that  guarantees  that  packets  exchanged  be¬ 
tween  hosts  on  different  networks  travel  on  the  shortest 
path  through  gateways.  This  means  that  if  one  gateway 
fails  and  there  is  an  alternative  gateway  available,  the 
alternative  gateway  will  be  used  automatically  without 
disrupting  host-to-host  connections. 

The  current  Oarpa  Internet  System  consists  of  more 
than  20  networks  and  gateways,  several  hundred  host 
computers,  and  several  thousand  terminals.  The  In¬ 
ternet  networks  are  connected  in  a  general  distributed 
fashion,  with  multiple  paths  between  networks  and 
alternate  paths  that  span  other  networks  (Fig.  1).  The 
gateways  dynamically  decide  the  best  path  for  a  mes¬ 
sage  to  be  routed  to  its  destination,  taking  into  account 
topology  changes  as  they  occur. 

Diverse  networks  make  up  the  Internet  System:  ter¬ 
restrial  packet-switching  networks  such  as  Arpanet 
and  BBN-Net;  satellite  networks  such  as  the  Atlantic 
Packet  Satellite  Network  (Satnet)  and  the  Oarpa-spon- 
sored  Wideband  Packet  Satellite  Network  (Wideband); 
local  networks  such  as  Ethernet  and  the  Norwegian 
Defense  Research  Establishment  (NDRE)  Ringnet;  and 
mobile  radio  networks  such  as  SRI  International’s  pack¬ 
et  radio  network.  These  networks  vary  in  characteris¬ 
tics  such  as  message  size,  speed,  delay,  reliability,  and 
local  address  format  (Table  1). 

It'a  all  in  the  family 

The  Darpa  research  community  has  developed  a  family 
of  protocols  that  provides  the  mechanisms  for  host 
computers  to  communicate  over  Internet.  These  pro¬ 
tocols  offer  services  that  may  be  lacking  in  the  underly¬ 
ing  networks  that  make  up  Internet.  As  a  result  of  the 
small  number  of  network  requirements,  new  networks 
are  easily  added. 

To  be  part  of  Internet,  a  network  needs  only  to  be 


able  to  deliver  messages  to  a  destination  and  have  a 
minimum  message  size.  The  family  of  Darpa  Internet 
protocols  then  provides  the  following  services: 

■  Datagrams 

■  Addressing 

■  Message  fragmentation  and  reassembly 

■  Data  reliability 

■  Message  sequencing 

■  Flow  control 

■  Connections 

The  Internet  System's  protocols  are  a  layered  family 
of  protocols,  as  shown  in  Figure  2.  The  two  main  pro¬ 
tocols  that  provide  user  data  transfer  are  the  Internet 
protocol  (IP)  (Ref.  1]  and  the  Transmission  Control 
protocol  (TCP)  [Ref.  2].  In  addition,  there  are  protocols 
for  specific  applications  such  as  terminal  traffic  (Tel¬ 
net).  file  transfer  (FTP),  and  electronic  mail  transfer 
(MTP).  Internet  also  has  specialized  protocols  for  func¬ 
tions  such  as  gateway  routing,  gateway  monitoring 
and  control,  and  error  reporting. 

Individual  network  protocols  are  not  specified  in  the 
Internet  System.  Instead,  each  network  has  its  own 
access  protocols.  For  instance.  Arpanet  uses  the  1822 
Host  and  IMP  protocol  (a  protocol  for  interconnection 
of  a  host  and  IMP)  [Ref.  3].  and  Satnet  uses  the  Host 
Satnet  protocol  [Ref.  4]. 

Individual  network  protocols  are  used  to  encapsulate 
the  Internet  protocols  for  transmission  across  that  net¬ 
work.  When  a  message  traverses  Internet,  each  gate¬ 
way  creates  a  new  network  header  appropriate  to  the 
next  network  (Fig.  3). 

Datagram  dalivtry 

The  IP  in  the  second  layer  of  the  Internet  protocol  fam¬ 
ily  transports  datagrams  across  an  interconnection  of 
networks.  Datagrams  are  messages  that  consist  of 
source  and  destination  addresses,  plus  data.  They  are 
not  required  to  be  delivered  reliably  or  in  sequence. 

No  type  of  connection  needs  to  be  set  up  to  send  or 
receive  them.  In  contrast,  virtual-circuit  services  are 
provided  by  high-level  end-to-end  protocols. 

A  major  advantage  of  the  datagram  approach  to 
gateways  is  that  networks  are  not  required  to  provide 
many  services  in  order  to  send  a  datagram.  Therefore, 
it  is  comparatively  easy  to  interconnect  networks  of 
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Z  Internet  protocot  reletionehipe.  The  layered  family  of 
Internet  protocols  permits  hosts  to  communicate  over 
Internet  and  provides  for  specific  applications. 

LAYERS 


I 


1  I  INOIVIOUAL  NETVraRK  MOTOCOl 


diverse  characteristics. 

The  IP  provides  two  basic  services  in  the  second 
layer;  addressing  and  fragmentation /reassembly.  A 
common  address  format  is  maintained  across  Internet. 
A-"  Jresses  are  fixed-length  (32  bits)  and  consist  of  the 


network  number  and  a  local  address.  The  network- 
number  field  contains  the  address  of  a  particular  net¬ 
work,  and  the  local-address  field  contains  the  address 
of  a  host  within  that  network. 

The  networks  that  make  up  Internet  have  different 
message  sizes.  The  IP  provides  a  fragmentation /reas¬ 
sembly  service  to  overcome  these  variations.  When  a 
datagram  originates  in  a  network  that  allows  large  mes¬ 
sages,  and  the  datagram  nust  traverse  a  network  with 
a  smaller  message  limit,  tfie  datagram  must  be  broken 
Into  smaller  "pieces,”  or  fragments.  The  IP  provides 
a  mechanism  to  permit  datagrams  to  be  fragmented 
and  to  be  later  reassembled  into  one  piece  at  the  des¬ 
tination  host. 

The  TCP,  in  the  third  layer,  is  a  connection-oriented, 
reliable  end-to-end  protocol.  It  provides  the  services 
necessary  for  reliable  message  transmission  over  the 
Internet  System. 

ITte  networks  that  make  up  Internet  are  not  required 
to  guarantee  that  all  datagrams  are  delivered.  Also, 
the  originator  of  a  datagram  does  not  necessarily  know 
through  which  networks  a  datagram  will  be  rout^  to 
arrive  at  Its  destination.  Therefore  it  is  necessary  to 
provide  message  reliability  end-to-end— that  is,  at  the 
source  and  the  final  destination.  To  address  these  re¬ 
quirements,  the  TCP  provides  reliability,  flow  control, 
multiplexing,  and  connection  functions. 

Reliability  is  achieved  through  checksums  (error¬ 
detecting  codes)  and  positive  acknowledgments  of  ail 
data.  Data  that  is  not  acknowledged  is  retr.\nsmitted. 

End-to-end  flow  control  lets  the  receiver  of  the  data 
regulate  the  rate  at  which  it  is  sent.  To  allow  many  pro¬ 
cesses  (applications)  within  a  single  computer  (for 
example,  many  terminals  talking  to  one  host)  to  use 


: .  Meseege  eneepsutetion.  When  a  message  traverses  sion  across  each  network.  When  the  message  reaches  a 
networks  on  Internet,  individual  network  protocols  are  gateway,  that  gateway  creates  a  new  network  header 
used  to  encapsulate  the  Internet  protocols  for  transmis-  appropriate  to  the  next  network. 
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Table  2  Network  table  for  BBN  gateway 

NETWORK  NAME 

NET  ADDRESS 

•route 

SATNET 

4 

OIRECTLY  CONNfCTEO 

ARPANET 

10 

OIRECTLY  CONNECFEO 

IINNH 

3 

1  HOP  VIA  RCC  10.3.0.72  (ARPANET  3/72) 

PUROUE-COMPUTER  SCIENCE 

192.5.1 

2  HOPS  VIA  PUROUE  10.2.0.37  (ARPANET  2/37) 

INTELPOST 

43 

2  HOPS  VIA  MILLS  10.3.0  17  (ARPANET  3/17) 

OECNETTEH 

3a 

3  HOPS  VIA  mills  10.3.0.17  (ARPANET  T/K) 

WIOEIANO 

21 

3  HOPS  VIA  RCC  10.3.0.72  (ARPANET  3/72) 

1  IN-PACKET  RADIO 

1 

2  HOPS  VIA  RCC  10.3.0.72  (ARPANET  3/72) 

OCN-COMMT 

29 

1  HOP  VIA  MILLS  10.3.0.17  (ARPANET  3/17) 

FIIERNET 

24 

3  HOPS  VIA  RCC  10.3.0.72  (ARPANET  3/72) 

IRA66-PACKET  RADIO 

9 

1  HOP  VIA  IRAGG  10.0.0.38  (ARPANET  0/38) 

CLARK  NET 

1 

2  HOPS  VIA  MILLS  10.3.0.17  (ARPANET  3'17) 

LCSNET 

11 

1  HOP  VIA  MIT  LCS  iO.0.0.77  (ARPANET  077) 

UN-TERMINAL  CONCENTRATOR 

1921.2 

3  HOPS  VIA  RCC  10.3.0.72  (ARPANET  3/72) 

MIKIERICHO 

192.U 

3  HOPS  VIA  RCC  t0.3i).72  (ARPANET  3  72) 

UCLNET 

11 

1  HOP  VIA  UCL  4.0.0  SO  (SATNtT  60) 

RSREMULL 

35 

1  HOP  VIA  UCL  4.0.0.60  (SATNET  60) 

RSRE-PPIN 

25 

2  HOPS  VIA  UCL  4.0.0  60  (UTNET  60) 

UN  PRANCISCO-PACKET  RAOIO-t 

S 

1  HOP  VIA  C3P0  10.1.0.51  (ARPANET  1,51) 

‘NAMES  ANO  ACRONYMS  IDENTIFY  GATEWAYS 

IN  TME  INTERNET  SYSTEM 

the  protocol  simultarwously.  the  protocol  provides  for 
ports  to  allow  individual  processes  to  be  identified.  The 
protocol  also  provides  a  mechanism  for  interprocess 
communications  between  computers. 

Open  the  gatee 

A  host  computer  that  wants  an  IP  datagram  to  reach 
a  host  on  another  network  must  send  the  datagram  lo 
a  gateway.  A  local-network  header  containing  the  ad¬ 
dress  of  the  gateway  is  attached  to  the  datagram  be¬ 
fore  it  is  sent  into  the  network.  When  the  packet  is  re¬ 
ceived  by  the  gateway,  its  local-network  header  is 
checked  for  possible  errors  and  the  gateway  performs 
any  necessary  host-to-network  protocol  functions. 

The  Internet  control  message  protocol  (ICMP)  (Ref. 

5)  is  the  control  protocol  associated  with  the  IP  that  is 
used  to  convey  error  and  status  information  to  Internet 
users.  For  example,  if  the  header  indicates  that  the 
packet  contains  an  Internet  datagram,  then  the  packet 
is  passed  to  the  internet  header  check  routine,  which 
performs  a  number  of  validity  tests  on  the  IP  header. 
Packets  that  tail  these  tests  are  discarded,  and  an  error 
packet  IS  sent  from  the  gateway  to  the  Internet  source 
of  the  packet 

After  a  datagram  passes  these  checks,  its  Internet 
destination  address  ts  examined  to  determine  if  the 
datagram  is  addressed  to  the  gateway.  Each  of  the 

OtlaCommuncaitorn/ August  1962 


gateway’s  Internet  addresses— one  for  each  network 
interface— is  checked  against  the  destination  address 
in  the  datagram.  If  a  match  is  not  found,  the  datagram 
is  passed  to  the  forwarding  routine.  It  the  datagram  is 
destined  for  the  gateway,  then  the  datagram  is  pro¬ 
cessed  according  to  the  protocol  in  the  IP  header 
Some  types  of  datagrams  that  might  be  addressed  to 
the  gateway  include  monitoring  packets,  gateway  rout¬ 
ing  packets,  or  remote  debugging  packets. 

Myiliple  hope 

Among  other  functions,  the  gateway  must  make  a  rout¬ 
ing  decision  lor  all  datagrams  that  are  to  be  forwarded 
The  routing  proceoure  provides  tAO  pieces  of  informa¬ 
tion.  which  network  interface  should  be  used  to  send 
the  packet,  and  which  destination  address  should  be 
in  the  packet’s  local-network  header 
The  gateway  maintains  a  network  table  that  contains 
an  entry  for  each  reachable  network  (Table  2)  The 
entry  consists  of  a  network  number  and  either  the  ad¬ 
dress  of  the  neighbor  gateway  on  the  shortest  route 
to  the  network  or  an  indication  that  the  gateway  is 
directly  connected  to  the  network  A  neighbor  gateway 
is  one  that  shares  a  common  network  with  this  gate¬ 
way  The  distance  measurement  that  is  used  to  deter¬ 
mine  which  neighbor  is  closest  is  "number  of  hops  " 

In  other  words,  a  gateway  is  considered  to  be  :ero 
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hops  from  its  directly  connected  networks,  one  hop 
from  a  network  that  is  reachable  via  one  other  gate¬ 
way.  and  so  on.  The  Gateway-to-Gateway  protocol 
(GGP)  [Ref.  6]  is  used  to  build  the  network  table. 

The  gateway  tries  to  match  the  destination  network 
address  in  the  IP  header  of  the  datagram  to  be  for¬ 
warded  with  a  network  in  its  network  table.  If  no  match 
is  found,  the  gateway  drops  the  datagram  and  sends 
an  ICMP  packet  to  the  IP  source.  If  the  gateway  does 
find  an  entry  for  the  network  in  its  table,  it  uses  the 
network  address  of  the  neighbor  gateway  entry  as  the 
local  networK  destination  address  of  the  datagram. 
However,  if  the  final  destination  network  is  one  to  which 
the  gateway  is  directly  connected,  the  destination  ad¬ 
dress  in  the  local-network  header  is  simply  built  from 
the  destination  address  in  the  datagram’s  IP  header. 

If  the  routing  procedure  decides  that  an  IP  datagram 
is  to  be  sent  back  out  of  the  same  network  interface 
from  which  it  was  read,  then  the  source  host  has 
chosen  a  gateway  that  is  not  on  the  shortest  path  to 
the  IP  final  destination.  The  datagram  wiii  still  be  for¬ 
warded  to  the  next  address  chosen  by  the  routing  pro¬ 
cedure.  but  a  redirect-ICMP  packet  will  also  be  sent 
to  the  IP  source  host  indicating  that  another  gateway 
should  be  used  to  send  traffic  to  the  final  IP  destination. 

Break  it  up 

After  the  routing  decision  is  complete,  the  datagram 
is  passed  to  the  fragmentation  procedure,  if  the  next 
network  through  which  the  datagram  must  pass  has 
a  smaller  maximum  packet  size  than  the  size  of  the 
datagram,  the  gateway  will  break  the  datagram  into 
fragments.  These  fragments  are  then  transported  as 
independent  datagrams  themselves  and  are  ultimately 
collected  and  assembled  at  the  destination  host  to 
recreate  the  original  datagram. 

The  gateway  now  builds  a  new  network  header  for 
the  datagram.  The  gateway  uses  the  intormation  ob¬ 
tained  from  its  routing  procedure  to  choose  the  proper 
network  interface  for  the  datagram  and  to  build  the 
destination  address  m  the  new  network  header. 

The  gateway  then  queues  the  packet  for  delivery  to 
its  destination.  It  also  enforces  a  limit  on  the  size  of  the 
output  queue  for  each  network  interface  so  that  a  slow 
network  does  not  unfairly  use  up  all  of  the  gateway's 
buffers  A  packet  that  cannot  be  queued  because  of 
the  limit  on  the  output-queue  length  is  dropped  Wheth¬ 
er  or  not  the  packet  is  retransmitted  depends  on  the 
type  of  packet 

Wnen  the  packet  finally  reaches  its  destination,  the 
network  header 'S  stripped  oft  and  the  information 
inside  the  IP  datagram  is  processed  In  addition,  it  the 
original  datagram  was  fragmented,  the  destination 
host  collects  alt  of  the  fragments  and  reassembles 
them  into  the  original  datagram 

To  provide  Internet  service,  the  IP  gateway  must 
support  a  variety  of  protocols  For  example,  the  gate¬ 
way  has  to  se.id  and  receive  packets  on  its  connected 
network  interfaces  Therefore,  it  must  implement  all  of 
these  networks'  access  protocols,  such  as  the  Arpanet 
1822  protocol  or  the  Sat.ner  Host  Access  protocol 

Since  ail  Internet  traffic  is  sent  m  the  form  of  internet 


datagrams,  the  gateway  must  also  implement  the  IP 
protocol.  In  addition,  the  gateway  sends  control  infor¬ 
mation.  such  as  "This  destination  network  is  unreach¬ 
able."  to  hosts  using  the  ICMP  protocol. 

Monitoring  and  support  of  gateways  is  aided  by  the 
Cross  Network  Debugger  protocol  [Ref.  7].  which  al¬ 
lows  remote  debugging  of  the  gateway,  and  the  Host 
Monitoring  protocol  [Ref.  8].  which  allows  the  gateway 
to  report  the  status  of  its  interfaces.  The  gateway  also 
has  an  internal  message  generator  that  is  used  as  a 
testing  facility. 

The  right  way 

The  IP  gateway  uses  the  GGP  tor  four  functions  con¬ 
cerned  with  routing: 

■  Determining  if  its  network  interfaces  are  operational 

■  Determining  if  its  neighbor  gateways  are  operational 

■  Building  a  table  of  networks  that  can  be  reached  via 
neighbor  gateways 

■  Adding  new  neighbor  gateways  and  new  networks 
to  its  network  table 

Gateways  use  the  information  obtained  from  GGP 
packets  to  ensure  that  a  datagram  uses  the  best  route 
througn  Internet  to  reach  its  destination. 

GGP  packets  are  sent  reliably  using  sequence  num¬ 
bers  and  an  acknowledgment  scheme.  The  gateway 
determines  if  its  netwoik  interfaces  are  up  by  sending 
GGP  packets,  called  "interface  probes."  addressed 
to  itself  every  15  seconds.  When  a  number  of  these 
probes  have  been  successfully  received,  the  interface 
is  declared  operational,  if  a  number  of  probes  are 
missed,  the  interface  is  declared  down. 

In  order  to  determine  whether  other  gateways  are 
operating  properly,  each  gateway  has  a  built-in  table 
of  neighbor  gateways.  Every  15  seconds,  a  gateway 
will  send  a  GGP  echo  packet  ("neighbor  probe")  to 
each  of  its  neighbors  to  determine  which  are  operation¬ 
al.  When  a  neighbor  gateway  has  echoed  a  number  of 
probes,  it  is  declared  operational.  However.  If  several 
probes  are  sent  to  a  neighbor  but  are  not  echoed,  the 
neighbor  is  declared  down. 

Whenever  a  gateway  determines  that  there  has  been 
a  change  m  Internet  routing,  such  as  when  it  declares 
one  of  Its  network  interfaces  to  be  down,  it  sends  a 
GGP-routing-update  packet  to  each  of  its  neighbors. 
This  packet  indicates  *cr  each  network  the  distance 
and  address  of  the  gateway  on  the  shortest  path  to 
the  network. 

On  receiving  a  routing  uodate.  a  gateway  will  recal¬ 
culate  Its  network  table  to  ensure  that  it  uses  the  neigh¬ 
bor  on  the  shortest  route  to  each  network  if  the  routing 
update  packet  is  from  a  new  neighbor  or  contains  infor¬ 
mation  about  a  new  network,  the  gateway  updates  its 
neighbor  or  network  tables  It  thereby  learns  about 
new  neighbors  and  networks  without  having  to  undergo 
reconfiguration 

Finding  the  alternate  path 

The  gateway  uses  the  information  in  its  routing  ,ables 
to  minimise  congestion  and  delay  by  adapting  its  rout¬ 
ing  to  the  Situation  For  example,  suppose  there  are 
two  gateways.  X  and  Y,  that  can  be  used  to  reach  net- 
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work  A.  When  gateway  X  goes  down,  all  of  its  neigh¬ 
bors  will  send  out  routing  updates  reporting  that  net¬ 
work  A  is  no  longer  reachable  via  gateway  X.  When  a 
gateway  receives  this  routing  update  it  will  recalculate 
its  network  table  and  find  that  gateway  Y  can  be  used 
to  reach  network  A.  Gateways  will  now  forward  data¬ 
grams  through  gateway  Y  to  reach  network  A  without 
disrupting  any  host-to-host  connections. 

Putting  it  together 

The  IP  gateway  operates  on  Digital  Equipment  Corpo¬ 
ration  PDP-1 1  or  ll\-^  1  16-bit  processors  under  a 
small  real-time  operating  system  called  the  Micro  Oper¬ 
ating  System  (MOS).  developed  by  SRI  International. 
MOS  provides  facilities  for  multiple  processes,  interpro¬ 
cess  communications,  buffer  management,  asynchro¬ 
nous  input /output,  and  a  shareable  real-time  clock. 

There  is  one  MOS  network  process  and  accompa¬ 
nying  data  structure  called  a  netblock,  which  contains 
information  about,  for  example,  network  interface 
status  and  queueing  for  each  network  that  is  directly 
connected  to  the  gateway.  Each  network  process  waits 
for  input  from  one  of  the  gateway's  interfaces.  When 
an  IP  datagram  is  received,  the  appropriate  network 
process  “wakes  Jp"  and  calls  procedures  to  forward 
the  datagram  toward  its  destination. 

The  IP  gateway  is  written  in  Macro- 1 1  assembly  lan¬ 
guage  instead  of  a  higher-level  language  because 
memory  is  limited  by  the  16-bit  address  space.  The 
gateway  code  occupies  about  10K  words  of  memory. 
The  MOS  operating  system  occupies  an  additional  3K 
words  of  code  space,  leaving  15K  words  for  buffers. 
These  buffers  are  shared  by  various  network  processes 
for  readit.g  and  writing  packets. 

Adding  support  to  connect  a  new  network  to  the  IP 
gateway  is  a  relatively  easy  task.  A  programmer  must 
write  a  device  driver  that  handles  the  hardware  inter¬ 
face  of  the  new  network  as  well  as  a  routine  to  imple¬ 
ment  the  new  host-to-network  access  protocol.  The 
programmer  also  creates  a  gateway-configura'ion  file 
that  contains  gateway-specific  information,  such  as 
interface-device  addresses.  The  macro  assembler  then 
assembles  a  new  gateway  program.  This  programming 
task  is  simplified  because  more  than  75  percent  of  the 
code  in  all  IP  gateways  is  identical  because  of  the  mod¬ 
ularity  of  the  gateway  software. 

Keeping  order 

Fault  isolation  can  be  a  major  problem  in  the  daily  op¬ 
eration  of  a  computer  network.  Some  issues  that  must 
be  resolved  are:  When  communications  fails,  what  is 
to  blame?  Is  the  problem  with  the  host  machine,  the 
network,  the  lines,  or  the  user  program? 

Internet  fault  isolation  is  even  more  difficult  because 
of  the  number  and  diversity  of  users,  networks,  paths, 
and  requirements  involved.  For  example,  tha  commu¬ 
nications  path  may  traverse  many  networks  and  gate¬ 
ways  so  that  the  potential  sources  of  communications 
disruption  are  multiplied. 

The  ability  to  identify  areas  of  congestion  is  also  a 
more  complex  task.  For  example,  poor  performance 
can  be  the  result  of  individual  networks  failing  io  pro¬ 


vide  users  with  adequate  throughput  or  of  a  bottleneck 
in  connections  between  networks. 

For  Bolt  Beranek  and  Newman,  the  solution  to  In¬ 
ternet  monitoring  and  control  is  to  apply  techniques 
much  like  those  used  to  operate  Arpanet.  In  fact,  tools 
developed  by  the  company  to  monitor  the  gateways 
that  are  the  switching  nodes  of  Internet  are  similar  to 
those  used  to  monitor  the  switching  nodes  in  Arpanet. 

These  tools  include  a  central  monitoring  facility 
called  the  network  operational  center  (NOG)  [Ref.  9] 
that  runs  on  BBN’s  C/70  computer  under  the  Unix 
operating  system.  The  NCXiJ  regularly  receives  traffic 
statistics  and  reports  of  important  events  from  each 
of  the  Internet  gateways.  Data  communications  users 
can  interrogate  the  NCX^  to  find  the  current  status  of 
any  Internet  gateway.  The  monitoring  facility  then 
prints  a  gateway  status  repon  (Table  3). 

The  NOC's  status-  and  event -monitoring  capabilities 
pinpoint  hardware  and  software  problems  during  the 
operation  of  Internet.  For  example,  when  communica¬ 
tions  is  disrupted  between  Internet  hosts,  the  NOC 
monitoring  tools  help  determine  whether  the  problem 
lies  with  a  gateway,  network,  communications  line,  or 
with  one  of  the  Internet  hosts.  Whenever  a  gateway 
receives  an  erroneous  packet,  a  report  that  identifies 
the  source  of  the  packet  is  sent  to  the  NCX^.  These 
reports  help  to  diagnose  malfunctioning  hardware  and 
aid  in  debugging  Internet  host  software. 
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ASSIGNED  NUMBERS 


Status  of  this  Memo 

This  memo  is  an  official  status  report  on  the  numbers  used  in 
protocols  in  the  ARPA- Internet  community.  Distribution  of  this  memo 
is  unlimited. 

Introduction 

This  Network  Working  Group  Request  for  Comments  documents  the 
currently  assigned  values  from  several  series  of  numbers  used  in 
network  protocol  inplementations .  This  RFC  will  be  updated 
periodically,  and  in  any  case  current  information  can  be  obtained 
from  Joyce  Reynolds.  The  assignment  of  numbers  is  also  handled  by 
Joyce.  If  you  are  developing  a  protocol  or  application  that  will 
require  the  use  of  a  link,  socket,  port,  protocol,  network  number, 
etc.,  please  contact  Joyce  to  receive  a  number  assignment. 

Joyce  Reynolds 

use  -  Information  Sciences  Institute 
4676  Admiralty  Way 

Marina  del  Rey,  California  90292-6695 

Phone:  (213)  822-1511 

ARPA  mail:  JKREYNOLDS@USC-ISIB.ARPA 

Most  of  the  protocols  mentioned  here  are  documented  in  the  RFC  series 
of  notes.  The  more  prominent  and  more  generally  used  are  documented 
in  the  "Internet  Protocol  Transition  Workbook"  [39]  or  in  the  old 
"ARPANET  Protocol  Handbook"  [40]  prepared  by  the  NIC.  Some  of  the 
items  listed  are  undocumented.  Further  information  on  protocols  can 
be  found  in  the  memo  "Official  ARPA- Internet  Protocols"  [104] . 

In  all  cases  the  name  and  mailbox  of  the  responsible  individual  is 
indicated.  In  the  lists  that  follow,  a  bracketed  entry,  e.g., 

[nn, iii] ,  at  the  right  hand  margin  of  the  page  indicates  a  reference 
for  the  listed  protocol,  where  the  number  ("r-'")  cites  the  document 
and  the  letters  ("iii")  cites  the  person.  Whenever  possible,  the 
letters  are  a  NIC  I dent  as  used  in  the  WHOIS  service. 
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ASSIGNED  NETWORK  NUMBERS 

The  network  numbers  listed  here  are  used  as  internet  addresses  by  the 
Internet  Protocol  (IP)  [39,92].  The  IP  uses  a  32-bit  address  field 
and  divides  that  address  into  a  network  part  and  a  "rest"  or  local 
address  part.  The  division  takes  3  forms  or  classes. 

The  first  type  of  address,  or  class  A,  has  a  7-bit  network  number 
and  a  24-bit  local  address.  The  highest-order  bit  is  set  to  0. 
This  allows  128  class  A  networks. 

12  3 

01234567890123456789012345678901 

10|  NETWORK  I  Local  Address  | 


Class  A  Address 

The  second  type  of  address,  class  B,  has  a  14-bit  network  number 
and  a  16-bit  local  address.  The  two  highest-order  bits  are  set  to 
1-0.  This  allows  16,384  class  B  networks. 

12  3 

01234567890123456789012345678901 

+  -  +  -  +  -  +  -  +  -4-  +  - 4 -  +  +  -  +  -  +  -  +  -  +  -  +  "  +  - +  -  +  -  +  -  +  -  +  -  +  +  -  +  -  +  + 

|1  0|  NETWORK  I  Local  Address  | 

4-+-4-4-4-4-4-4-+-4-4-4-4-4-4-+-4-4-4-4-4-4-4-+-4-4-4-4-4-+-4-4-4 


Class  B  Address 

The  third  type  of  address,  class  C,  has  a  21-bit  network  number 
and  a  8-bit  local  address.  The  three  highest-order  bits  are  set 
to  1-1-0.  This  allows  2,097,152  class  C  networks. 

12  3 

01234567890123456789012345678901 

4-4-4-4-4-4-4“4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 

|1  1  0|  NETWORK  I  Local  Address  | 

4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4 


Class  C  Address 

Not^^*  No  addresses  are  allowed  with  the  three  highest-order  bits 
set  to  1-1-1.  These  addresses  (sometimes  called  "class  D")  are 
reserved . 
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One  commonly  used  notation  for  internet  host  addresses  divides  the 
32-bit  address  into  four  8-bit  fields  and  specifies  the  value  of  each 
field  as  a  decimal  number  with  the  fields  separated  by  periods.  This 
is  called  the  "dotted  decimal"  notation.  For  example,  the  internet 
address  of  USC-ISIB.ARPA  in  dotted  decimal  is  010.003.000.052,  or 
10.3.0.52. 

The  dotted  decimal  notation  will  be  used  in  the  listing  of  assigned 
network  numbers.  The  class  A  networks  will  have  nnn . rrr . rrr . rrr ,  the 
class  B  networks  will  have  nnn. nnn. rrr  .rrr,  and  the  class  C  networks 
will  have  nnn . nnn . nnn . rrr ,  where  nnn  represents  part  or  all  of  a 
network  number  and  rrr  represents  part  or  all  of  a  local  address. 

There  are  four  categories  of  users  of  Internet  Addresses:  Research, 
Defense,  Government  (Non-Defense) ,  and  Commercial .  To  reflect  the 
allocation  of  network  identifiers  among  the  categories,  a 
one-character  code  is  placed  to  the  left  of  the  network  number:  R  for 
Research,  D  for  Defense,  G  for  Government,  and  C  for  Commercial  (see 
^spendix  A  for  further  details  on  this  division  of  the  network 
identification) . 

Network  numbers  are  assigned  for  networks  that  are  connected  to  the 
ARPA- Internet  and  DDN- Internet,  and  for  independent  networks  that  use 
the  IP  family  protocols  (these  are  usually  commercial) .  These 
independent  networks  are  marked  with  an  asterisk  preceding  the 
number . 

The  administrators  of  independent  networks  must  apply  separately  for 
permission  to  interconnect  their  network  with  either  the 
ARPA- Internet  of  the  DDN-Interr.et .  Independent  networks  should  not 
be  listed  in  the  working  tables  of  either  the  ARPA- Internet  or 
DDN- Internet  hosts  or  gateways. 

For  various  :  asons,  the  assigned  numbers  of  networks  are  sometimes 
changed.  To  ease  the  transition  the  old  number  will  be  listed  for  a 
transition  period  as  well.  These  "old  number"  entries  will  be  marked 
with  a  "T"  following  the  number  and  preceding  the  name,  and  the 
network  name  will  be  suffixed  "-TEMP". 

Special  Addresses: 

In  certain  contexts,  it  Is  useful  to  have  fixed  addresses  with 
functional  significance  rather  than  as  identifiers  of  specific 
hosts.  When  such  usage  is  called  for,  the  address  zero  is  to  be 
interpreted  as  meaning  "this",  as  in  "this  network".  The  address 
of  all  ones  are  to  be  interpreted  as  meaning  "all",  as  in  "all 
hosts".  For  exanple,  the  address  128.9.255.255  could  be 
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interpreted  as  meaning  all  hosts  on  the  network  128.9.  Or,  the 
address  0.0.0.37  could  be  interpreted  as  meaning  host  37  on  this 
network . 

Assigned  Network  Numbers 
Class  A  Networks 


*  Internet  Address  Name 


Network 


References 


000. 

004. 

006. 

007. 

008. 

010. 

Oil. 

012. 

014. 

018. 

021. 

022. 

023. 

024. 

025. 


027 
028 
029 
030 
G*031 
R  032 
R  036 
R  039 
R  041 
R  044 
001 
005 
009 
013 
015 
019 
033 
037 
040 
042 
045 
127 


rrr . 
rrr . 
rrr. 
rrr . 
rrr. 
rrr . 
rrr . 
rrr. 
rrr . 
rrr . 
rrr. 
rrr. 
rrr. 
.rrr. 
,rrr . 
,rrr . 

rrr. 

,rrr . 
.rrr. 
.rrr. 
.rrr . 
.rrr . 
.rrr . 
.rrr. 
.rrr. 
.rrr. 
.rrr. 
.rrr. 
.rrr . 
.rrr . 
.rrr . 
.  '■rr . 
.rrr 
.  rrr 

•  rrr 
.rrr 

•  rrr 

•  rrr 


rrr . 
rrr . 
rrr . 
rrr . 
rrr. 
rrr. 
rrr . 
rrr. 
,rrr . 
.rrr. 
.rrr. 
.rrr . 
.rrr. 
.rrr . 
,rrr . 
,rrr . 
.rrr. 
.rrr . 
.rrr . 
.rrr. 
.rrr. 
.rrr. 
.rrr. 
.rrr . 
.rrr. 
.rrr. 
.rrr 
.  rrr 
.rrr 

•  rrr 
.rrr 

•  rrr 
.  rrr 
.rrr 
.  rrr 

•  rrr 
.rrr 
.  rrr 


rrr 

rrr 

rrr 

rrr 

rrr 

rrr 

.rrr 

.rrr 

.rrr 

.rrr 

.rrr 

.rrr 

.rrr 

.rrr 

.rrr 

.rrr 

.rrr 

.rrr 

.rrr 

.rrr 

.rrr 

.rrr 

.rrr 

.rrr 

•  rrr 

•  rrr 

•  rrr 
.rrr 
.rrr 
.rrr 
.rrr 
.rrr 
.rrr 
,  rrr 

•  rrr 
.rrr 
.  rrr 
.  rrr 


SATNET 

T  YPG-NET-TEMP 
T  EDN-TEMP 
T  BBN-NET-TEMP 
ARPANET 
DODIIS 
ATT 
PDN 

T  MIT-TEMP 
DDN-RVN 
DISNET 
DDN-TC-NET 
MINET 
RSRE-EXP 
MILNET 


Reserved  [JBP] 
Atlantic  Satellite  Network  [SHB] 
Yuma  Proving  Grounds  [10,BXA] 
DCEC  EDN  [ECS] 
BBN  Network  [JSG5] 
ARPANET  [10,40,SA2] 
DoD  INTEL  INFO  SYS  [AY7] 
ATT,  Bell  Labs  [MEI12] 
Public  Data  Network  [REK4] 
MIT  Network  [20, 103,DDC1] 


DDN-RVN 
DISNET 

DDN-TestCell -Network 

MINET 

RSRE 

MILNET 


T  NOSC-LCCN-TEMPNOSC  /  LCCN 


WIDEBAND 
T  MILX25-TEMP 
T  ARPAX25-TEMP 
UCDLA-NET 
UCL-TAC 
T  SU-NET-TEMP 
T  SRnrtT-TEMP 
BBN-TEST-A 
AMPRNET 
-003.rrr .rrr .rrr  Unassigned 
Unassigned 
Unass i gned 
Unassigned 
-017 . rrr . rrr . rrr  Unassigned 
-020 .rrr .rrr .rrr  Unassigned 
-035.rrr .rrr .rrr  Unassigned 
-038.rrr .rrr .rrr  Unassigned 
Unassigned 
-043 .rrr .rrr .rrr  Unassigned 
-126 .rrr .rrr .rrr  Unassigned 
Reserved 


[MLC] 
[FLM2] 
[DH17] 
[10,DHH] 
[RNMl] 
[FLM2] 
[RH6] 
[CJW2] 
[MLC] 
[MLC] 
[CXL] 
[PK] 


Wide  Band  Satellite  Net 
MILNET  X.25  Temp 
ARPA  X.25  Temp 
UCDLA-CATALOG-NET 
UCL  TAC 

Stanford  University  Network [PA5] 
SRI  Local  Network  [GEOF] 

BBN-GATE-TEST-A  [RH6] 

Amateur  Radio  Experiment  Net[HM] 

[JBP] 
[JBP] 


[JBP] 

[JBP] 

[JBP] 

[JBP] 

[JBP] 

[JBP] 

[JBP] 

[JBP] 

[JBP] 

[JBP] 
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Class  B  Networks 


*  Internet  Address  Name 


Network 


References 


128. 000 .rrr .rrr 
R  128. 001. rrr .rrr 
R  128. 002. rrr. rrr 
R  128. 003. rrr .rrr 
R  128. 004. rrr .rrr 
R  128. 005. rrr .rrr 
R  128. 006. rrr .rrr 
R  128. 007. rrr. rrr 
R  128. 008. rrr. rrr 
R  128. 009. rrr .rrr 
R  128. 010. rrr. rrr 
R  128.011 .rrr .rrr 
R  128.012 .rrr .rrr 
D  128. 013. rrr. rrr 
R  128. 014. rrr. rrr 
R  128. 015. rrr .rrr 
R  128. 016. rrr. rrr 
D  128. 017. rrr. rrr 
R  128. 018. rrr .rrr 
D  128. 019. rrr. rrr 
D  128.020 .rrr .rrr 
R  128. 021. rrr .rrr 
R  128.022 .rrr. rrr 
R  128. 023. rrr .rrr 
R  128. 024. rrr .rrr 
D  12S . 025 . rrr . rrr 
D  128. 026. rrr .rrr 
D  128. 027. rrr. rrr 
D  128. 028. rrr , rrr 
R  128. 029. rrr .rrr 
R  128.030 .rrr. rrr 
R  128. 031. rrr .rrr 
R  128. 032. rrr. rrr 
R  128. 033. rrr .rrr 
R  128. 034. rrr. rrr 
R  128. 035. rrr .rrr 
R  128 . 0 36 . rrr . rrr 
D  128. 037 .rrr .rrr 
D  128 . 038 . rrr . rrr 
R  128. 039. rrr .rrr 
R  128.040 .rrr .rrr 
R  128. 041. rrr. rrr 
R  128. 042. rrr. rrr 
R  128. 043. rrr. rrr 


BBN-TEST-B 

CMU-NET 

LBL-CSAM 

DCNET 

FORDNET 

RUTGERS 

DFVLR 

UMDNET 

ISI-NET 

PURDUE-CS-NET 

BBN-CRONUS 

SU-NET 

MATNET 

BBN-SAT-TEST 

SINET 

UCLNET 

MATNET-ALT 

SRINET 

EDN 

BRLNET 

SE-PR-1 

SF-PR-2 

BBN-PR 

ROCKWELL-PR 

BRAOG-PR 

SAC-PR 

DEMO-PR-1 

C3-PR-TEMP 

MITRE 

MIT-NET 

MIT-RES 

UCB- ETHER 

BBN-NET 

NOSC-LCCN 

CISLTESTNETl 

YALE -NET 

^-NET* 

NSWC-NET 

NTANET 

UCL-NET-A 

UCL-NET-B 

RICE-NET 

DRENET 


Reserved  [JBP] 

BBN-GATE-TEST-B  [RH6] 

CMU-Ethernet  [HDW2] 

LBL  -CSAM-RESEARCH  [  JS  38] 

LINKABIT  DCNET  [69,DLM1] 

FORD  DCNET  [69,DLM1] 

RUTGERS  [CLH3] 

DFVLR  DCNET  Network  [HDCl] 

Univ  of  Maryland  DCNET  [69,DLiMl] 
USC-ISI  Local  Network  [CMR] 

Purdue  Con^uter  Science  [— 
BBN  DOS  Project  [64"wiM] 

Stanford  University  Net  [LB3] 
Mobile  Access  Terminal  Net  [SHB] 
BBN  SATNET  Test  Net  [SHB] 

LLL-Sl-NET  [EAKl] 

University  College  London  [PK] 
Mobile  Access  Terminal  Alt  [SHB] 
SRI  Local  Network  [GEOF] 

DCEC  EDN  [EC5] 

BRLNET  [10,MJM2] 

SF-1  Packet  Kaaio  Network  [JtM] 
SF-2  Packet  Radio  Network  [JEM] 
BBN  Packet  Radio  Network  [JAW3] 
Rockwell  Packet  Radio  Net  [EHP] 
Ft.  Bragg  Packet  Radio  Net  [JEM] 
SAC  Packet  Radio  Network  CBG5] 
Demo-1  Packet  Radio  Network [LCS] 
Testbed  Develooment  PR  NET  [BG5] 


MITRE  Cablenet 
MIT  Local  Network 
MIT  Research  Network 
UC  Berkeley  Ethernet 
BBN  Network 
NOSC  /  LCCN 
Honeywell 
YALE  NET 

Yuma  Proving  Grounds 

NSWC  Local  Host  Net 

NDRE-TIU 

UCL 

UCL 

Rice  University 
Canada  REF  ARPANET 


[111,'IML] 
[DDCl] 
[DDClj 
[DAMl] 
[JSG5] 
[RH6] 
[52,53. JLM23] 
[128, JOS] 
[lO.BXA] 
[RLH2] 
[PS3] 
[RC7] 
[RC7] 
[69. 128. PGM] 
[10. JR17] 
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D  128.044.rrr .rrr 
C  128. 045. rrr .rrr 
R  128. 046. rrr .rrr 
D  128. 047. rrr .rrr 
G*  128 . 048 . rrr . rrr 
R  128. 049. rrr .rrr 
G  128. 050 .rrr .rrr 
G  128. 051. rrr .rrr 
R  128.052 .rrr .rrr 
R  128. 053. rrr .rrr 
R  128. 054. rrr .rrr 
R*128.055.rrr .rrr 
D  128. 056. rrr .rrr 
D  128. 057. rrr .rrr 
C*128.058.rrr .rrr 
R  128. 059. rrr .rrr 
D  128. 060 .rrr .rrr 
R*128.061.rrr.rrr 
R  128. 062 .rrr .rrr 
R  128. 063. rrr .rrr 
R  128. 064. rrr .rrr- 
D  128. 080. rrr .rrr 
R  128.081 .rrr .rrr 
R  128.082 .rrr .rrr 
R  128. 083. rrr .rrr 
R  128. 084. rrr .rrr 
C*128.085.rrr.rrr 
R  128. 086. rrr .rrr 
R  128. 087, rrr .rrr 
R*128.088.rrr .rrr 
R  128. 089. rrr .rrr 
C*128.090.rrr .rrr 
R  128. 091. rrr .rrr 
R  128. 092. rrr .rrr 
R*128.093.rrr .rrr 
R*128.094.rrr.rrr 
R* 128. 095. rrr. rrr 
C* 128. 096. rrr .rrr 
R  128. 097. rrr .rrr 
128. 098. rrr .rrr 
191 . 255 . rrr . rrr 
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WSMR-NET 

White  Sands  Network 

[TBS] 

DEC-WRL-NET 

DEC  WRL  Network 

[128,RKJ2] 

PURDUE -NET 

Purdue  Campus  Network 

[CAK] 

TACTNET 

Tactical  Packet  Net 

[9,ICrP] 

UCT)LA-NET-B 

UCDLA-Network- B 

[10,CXL] 

NOSC-ETEiER 

NOSC  Ethernet 

[128,RLB3] 

COINS 

COINS  On-Line  Intel  Net  [RLS6] 

COINSTNET 

COINS  TEST  NETWORK 

[RLS6] 

MIT-AI-NET 

MIT  AI  NET 

[128, MDC] 

SAC -PR-2 

SAC  PRNET  Number  2 

[BG5] 

UCSD 

UC  San  Diego  Network 

[128,GH29] 

MFENET 

LLNI.  MFE  Network 

[109, DRP] 

USNA-NET 

US  Naval  Academy  Network  [TXS] 

DEMO-PR-2 

Demo -2  Packet  Radio  Net  [LCS] 

SPAR 

Schl’jmberger  PA  Net 

ri28,RXB'l 

CU-NET 

Columbia  University 

[128, LH2] 

NRL-LAN 

NRL  Lab  Area  Net 

[WF3] 

GATECH 

Georgia  Tech 

[128, SXA] 

MCC-NET 

MCC  Corporate  Net 

[128, CBD] 

BRL-SUBNET 

BRL-SUBNET-EXP 

[RBNl] 

128. 079. rrr .rrr 

Net  Dynamics  Exp 

[ZSU] 

CECOMNET 

CECOM  EPR  NET 

[PFS2] 

SCRC -ETHERNET 

SCRC  ETHERNET 

[128, CH2] 

UMICH 

UOFMICHIGAN 

r8,HWB] 

UTAUSTIN 

U.  Texas  Austin 

[128,JSQ1] 

Cornell -NLi 

Cornell  Backbone  Net 

[128, BN9] 

DRILL-NET 

Teleco  Drilltech  Net 

[DBJ] 

MRC 

UK.CO.GEC.RL.MRC 

[RHC3] 

HIRST 

UK.CO.GEC.RL.HRC 

[RHC3] 

HP -NET 

HEWLETT-PACKARD -NET 

[AXG] 

BBN-ENET-TEMP 

BBN  ETHER  NETWORK 

[128, SGC] 

PQS 

PERQ  SYSTEMS  CORP 

[128, DXS] 

UPENN 

UPenn  Campus  Network 

[128, IXW] 

INTELLINET 

INTELLICCRP  NET 

[12b,  DAVE] 

INRIA-ROCQU 

INRIA  Rocquencourt 

[MXAl] 

SYSNET 

AT&T  SYSNETWORK 

[EXY] 

WASHINGTON 

Comp  Sci  Ether  Net 

[128.RA17] 

BELLCORE-NET 

BELLCORE-NET 

[I'K28] 

UCLANET 

UCLA  Network 

[BJL5] 

•191 . 254. rrr .rrr 

Unassigned 

[JBP] 

Reserved 

[JBP1 
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RFC  960 

Network  Numbers 

Class  C  Networks 

*  Internet  Address 

Name 

Network 

References 

192.00C.000.rrr 

Reserved 

[JBP] 

R  192. 000. 001. rrr 

BBN-TEST-C 

BBN-GATE-TEST-C 

[RH6] 

192. 000. 002. rrr- 

192. 000. 255. rrr 

Unassigned 

[JBP] 

R  192. 001. 000. rrr- 

192. 001. 004. rrr 

BBN  local  networks 

[SGC] 

R  192. 001. 005. rrr 

BBN-ENET2 

BBN-ENET2 

[SGC] 

R  192. 001. 006. rrr 

BBN  local  network 

[SGC] 

R  192. 001. 007. rrr 

BBN-ENET 

BBN-ENET 

[SGC] 

R  192. 001. 008. rrr 

BBN  local  network 

[SGC] 

R  192. 001. 009. rrr 

BBN-ENET3 

BBN-ENET3 

[SGC] 

R  192. 001. 010. rrr 

BBN-NETR 

BBN-NETR 

[SGC] 

R  192. 001.  on.  rrr 

BBN-SPC-ENET 

BBN-SPC-ENET 

L— - - J 

R  192. 001. 012. rrr- 

192. 003. 255. rrr 

BBN  local  networks 

[SGC] 

R*192.004.000.rrr- 

192. 004. 255. rrr 

BELLCORE-NET 

[128.PK28] 

R  192. 005. 001. rrr 

CISLHYPERNET 

Honeywell 

[JLM23] 

R  192. 005. 002. rrr 

Wise 

Univ  of  Wisconsin  Madi 

.son  [RS23] 

C  192. 005. 003. rrr 

HP-DESIGN-AIDS  HP  Design  Aids 

[NXK] 

C  192. 005. 004. rrr 

HP-TCG-UNIX 

Hewlett  Packard  TCG  Unix  [NXK] 

R  192. 005. 005. rrr 

DEC-MRNET 

DEC  Marlboro  Ethernet 

[119, KWP] 

R  192. 005. 006. rrr 

DEC-MRRAD 

DEC  Marlboro  Developmt  [119, KWP] 

R  192. 005. 007. rrr 

CIT-CS-NET 

Cal tech- CS -Net 

[126, DSW] 

R  192. 005. 008. rrr 

WASHINGTON 

University  of  Washington  [JAR4] 

R  192. 005. 009. rrr 

AERONET 

Aerospace  Labnet 

R  192. 005. 010. rrr 

ECLNET 

use - ECL -CAMPUS -NET 

[MAB4] 

R  192. 005.  on.  rrr 

CSS -RING 

SEISMIC-RESEARCH-NET 

[RR2] 

R  192. 005. 012. rrr 

UTAH-NEI 

UTAH-COMPUTER- SCI ENCE - 

'NET  [GW22] 

R  192. 005. 013. rrr 

GSWDNET 

Comp ion  Network 

[128, FAS] 

R  192. 005. 014. rrr 

RAND-NET 

RAND  Network 

[128,  JDG] 

R  192. 003.015. rrr 

NYU-NET 

NYU  Network 

[EF5] 

R  192. 005. 016. rrr 

LANLLAND 

Los  Alamos  Dev  LAN 

[128,JCn] 

R  192. 005. 017. rrr 

NRL-NET 

Naval  Research  Lab 

[API 

R  192. 005. 018. rrr 

IPTO-NET 

ARPA-IPTO  Office  Net 

[SA2] 

R  192. 005. 019. rrr 

UCIICS 

UCI-ICS  Res  Net 

[MIR] 

R  192. 005. 020. rrr 

CISLTTYNET 

Honeywell 

[JLM23] 

D  192.005. 021. rrr 

BRLNETl 

BRLNETl 

[10,MJM2] 

D  192. 005. 022. rrr 

BRLNET2 

BRLNET2 

[10,MJM2] 

D  192. 005. 023. rrr 

BRLNET3 

BRLNET3 

[10,MJM2] 

D  192. 005. 024. rrr 

BRLNET4 

BPniET'l 

no  M.TM71 

D  192. 005. 025. rrr 

BRLNET5 

BRLNET5 

[10.MJM2] 

D  192. 005. 026. rrr 

WSRDCOA-NET 

NSRDC  Office  Auto  Net 

[TC4] 

D  192. 005. 027. rrr 

DTiNSHDC-NET 

DTNSRDC-NET 

[TC4] 

R  192. 005. 028. rrr 

RSRE-NULL 

RSRE-NULL 

[RNMl] 

R  192. 005. 029. rrr 

RSRE-ACC 

RSPP-ACC 

[RNMl] 

R  192. 005. 030. rrr 

RSRE-PR 

RSRE-PR 

[RNMl] 

R*192.005.031.rrr 

SIEMENS-NET 

Siemens  Research  ;’etwork  [PXN] 

Reynolds  &  Postel 

[Pago  7] 

3>181 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


Assigned  Numbers 
Network  Numbers 


RFC  960 


R  192. ( 
R  192. ( 
R  192. ( 
R  192. ( 
R  192. ( 
R  192. ( 
R  192. ( 
R  192. ( 
R  192. ( 
D  192.  ( 
D  192. ( 
R  192.  ( 
R  192. ( 
R  192. ( 
R  192. ( 
R  192. ( 
R  192. < 
R  192. < 
R  192.1 
R  192. < 
R  192.1 
R  192.1 
R  192.1 
R  192. 
C  192.1 
R  192. 
R  192. 
R*192. 
R*192. 
R*192. 
R*192. 
R  192. 
R  192. 
R  192. 
R  192. 
R  192. 
R  192. 
G  192. 
R  192. 
R*192. 
R  192, 
R  192. 
R  192. 
R  192. 
R  192. 
R  192. 
R*192. 
R*192. 


CISLTESTNET2 

CISLTESTNET3 

CISLTESTNET4 

RIACS 

CORNELL-CS 

UR-CS-NET 

SRI-C3ETOER 

UDEL-EECIS 

PUCC-NET-A 

WISLAN 

AFDSC -HYPER 

CUCSNET 

Farber-PC-Net 

AIDS-NET 

NTA-RING 

NSRDC 

PURDUE-CS-EN 

UCSF 

CIH-CS-NET 
Theorynet 
NLM-ETHER 
UR-CS-ETOER 
AER0-A6 
UCLA-CECS 
TARTAN-NET 
UDEL-CC 
CS?^-PDN 
INRIA  SM90 
SM90  XI 
SM90  X2 
LIT?  SM90 
AMES-NAS-NET 
NPRDC- Ether 
HARV-NET 
CECOM-ETOER 
AERO- 130 
UIUC-NET 
CELAN 
SAC-ETHER 
■192. 005. 087. rrr 
YALE-EE-NET 
HARV-APPOLLO 
HARV- ETHER 
PURDUE-ECNl 
BRAOG-ETHER 
SRI -DEMO 
SDCRDCF-IOMB 
SDCRDCF-3MB 


Honeywell  [l 

Honeywell  [ 

Honeywell  [ 

USRA 

CORNELL  CS  Research 
U  of  R  CS  3Mb  Net 
SRI-AITAD  C3ETHERNET 
Udel  EECIS  LAN 
PURDUE  Comp  Cntr  Net 
WIS  Research  LAN 
AFDSC  Hypemet 
Columbia  CS  Net 
Farber  PC  Netvfork 
AlilDS  Network 
NDP.E-RING 
NSRDC 

Purdue  CS  Ethernet 


[52,53,JLM23] 
[32,33,JLM23] 
[32,33, JLM23] 
[113,RLB1] 
[128, DK2] 
[67,LB1] 
r  [128,  BG5] 
[120, CC2] 
t  [JRS8] 

[111,JRM1] 
[MCAl] 
[128, LH2] 
[DJF] 
[128, KFD] 
[PS3] 
[PXM] 
[128, CAK] 


Univ  of  Calif,  San  Fran [120, TF6] 


Chalmers  CSN  Net 


[120, UXB] 


Cornell  Theory  Center  [128,AB13] 


NLM-LHNCBC-ETHERNET 
U  of  R  CS  10Mb  Net 
Aerospace 
UCLA-CECS  Network 
Tarta*';  Labs 
uDEL  Comp  Center 
CSNET  X.25  Network 
Inria  GIP  SM-90 
Inria  SM-90  exp.  1 
Inria  SM-90  exp.  2 
LIT?  SM-90 
NASA  ARC  NAS  LAN 
NPRDC  TRCF  Ethernet 
Harvard  Comp  Scl  Net 
CECOM  ADDCOMPE  ETHER 
AEROSPACE- 130 
Univ  of  IL  at  Urbana 
COINS  Exper.  LAN 
SAC  C3  Ethernet 
U  Chicago 
YALE-EE-NET 
Harvard  University 
Harvard  CS  Ethernet 
Purdue  ECN 
SRI  Bragg  Ether 
SRI  Ether  Demo 
SDC  R&D  primary  net 
SDC  R&D  old  net 


[92,JA1] 
[67,LB1] 
[2,LCN] 
[128,  RBW] 
[SXB] 
[120,RR18] 
[60,RDR4] 
[MXS] 
[MXS] 
[MXS] 
[MXS] 
[119,MF31] 
[LRB] 
[SB28] 
[120, GIH] 
[LCN] 
[128, AKC] 
[MXM] 
[128, BC5] 
TTXN] 
ri28  AG22] 
[4,SB28] 
[SB28] 
[36,55,0G11] 
[121, GIH] 
[121, GIH] 
[128,DJV1] 
[67,DJV1] 
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R*192.005.096.rrr 
R*192.005.097.rrr 
R*192.005.098.rrr 
R  192. 005. 099. rrr 
R*192.005.100.rrr 
R  192. 005. 101. rrr 
R  192. 005. 102. rrr 
0*192.005.103. rrr 
R  192. 005. 104. rrr 
R  192. 005. 105. rrr 
0*192. 005. 106. rrr 
R*192.005.107.rrr 
R*192.005.108.rrr 
R*192.005.109.rrr 
R*192.005.110.rrr 
R*  192. 005. 111. rrr 
R*192.005.112.rrr 
R*192.005.113.rrr 
0*192. 005. 114. rrr 
0*192. 005. 115. rrr 
R  192. 005. 116. rrr 
R  192. 005. 117. rrr 
R  192. 005. 118. rrr 
R  192. 005. 119. rrr 
R  192. 005. 120. rrr 
R  192. 005. 121. rrr 
R  192. 005. 122. rrr 
R  192. 005. 123. rrr 
R  192. 005. 124. rrr 
R  192. 005. 125. rrr 
R  192. 005. 126. rrr 
R  192. 005. 127. rrr 
R  192. 005. 128. rrr 
R  192. 005. 129. rrr 
R  192. 005. 130. rrr 
R  192. 005. 131. rrr 
R  192. 005. 132. rrr 
R* 192. 005. 133. rrr 

192.005. 134. rrr 
C*1 92. 006, 000. rrr 
0*192.007.000. rrr 
0*192 .008. 000. rrr 
0*192. 009. 000. rrr 
0*192. 010. 000. rrr 
R  192. 010. 041. rrr 
0*192. 010. 042. rrr 
0*192. Oil. 000. rrr 
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UBO-OS-NET 

UOLA-OS-LNI 

UOLA-PIO 

SPAOENET 

HCSO-NET 

PUOO-NET-B 

PUOO-RHF-NET 

TYM-NTD-NET 

THINK-INET 

OOA-POND 

BITSTREAM 

PASO-EIHER 

PASO-BB 

OWR-JOO-T 

CWR-JGC-L 

OWR-QUAD 

OWR-OAISR 

OWR-OES 

I2-RING-1 

I2-ETHER-1 

BRAOGNET-1 

BRAGGNET-2 

BRAOGNET-3 

BRACX»JET-4 

HRAOGNET-5 

BElAGCSKET-6 

BRAOGNET-7 

BRACX»JET-8 

BRAOGNET-9 

BRAOGNET-10 

BRAOGNET-11 

BRAOGNET-12 

BRAOGNET-13 

BRA0a>IET-i4 

BRAOGNET-15 

BRAOGNET-16 

BRAOGNET-17 


UBO  Oomp  Sci  Net  [128, PXB] 
UOLA  OS  LNI  Network  [RBW] 
UOLA  PIO  Network  [128, RBW] 
S-1  Workstation  Net.  [128,TW11] 
Honeywell  OSO  Net  [128, RL2] 
Purdue  Gateway  Network  [JRS8J 
PUOO  RHF  Based  Net  [JRS8] 
Tymnet  NTO  Ethernet  [SMF] 
Thinking  Machines  [128,BJN1] 
OOA  Ethemetl  (POND)  [128, AL6] 
Bitstream  Type  Foundry  [128, PXA] 
IBM  PASO  Ethernet  [128, GXL] 
IBM  PASO  Broadband  [56, GXL] 
ARJOO  TOPS-20  NET  [128,JAG3] 
ARJCG  LOCAL  NET  [12R,.TAr.3] 
Ganpus  QUAD  NET  [128,JAG3] 
OAISR  LOOAL  NET  [128,JAG3] 
OES  LOOAL  NET  [JAG3] 
INTERMETRIOS  PRONET  [128, NXH] 
INTERMEIRIOS  ETHER  [128,  NXH] 
BRAOG/ADDOOMPE  [128,BG25] 
BRAOG/ADDOOMPE  [128,BG25] 
BRAOG/ADDOOMPE  [128,BC25] 
BRAOG/ADDOOMPE  [128,BG25] 
BRAOG/ADDOOMPE  [128,BC25] 
BRAGG/ADDCOnrE  [i26,BG25] 
BRAOG/ADDOOMPE  [128,BG25] 
BRAOG/ADDOOMPE  [128,BG25] 
BRAOG/ADDOOMPE  [128,BG25] 
BRAOG/ADDOOMPE  [12B.BG25] 
BRAOG/ADDOOMPE  [128,BG25] 
BRAOG/ADDOOMPE  [123,BG25] 
BRAGG/.ADDOOMPE  [128,BG25] 
BRACG/AEOOOMPE  [128,BC251 
BRAOG/ADDOOMPE  [128,BG25] 
BRAOG/ADDOOMPE  [128,BG25] 
BRAOG/ADDOOMPE  [128,BG25] 


PEROEPT-AI  Perceptronics,  AI  Div. 

[KXO] 

192. 005. 255. rrr  Unas,signed  [JBP] 

192.006. 255. rrr  H^lett  Packard  [AXGj 

192. 007. 255. rrr  Oooputcr  Oonsoles,  Inc.  [RAll] 
192. 008. 255. rrr  ^artacus  Oocputers,  Inc.  [SXM] 
192. 009. 255. rrr  SUN  Microsystems ,  Inc.  [BN4] 
192. 010. 040. rrr  Symbolics,  Inc.  [OH2] 

T  SORO-ETHERNET  SORO  ETHERNET  [128, 0H2] 

192. 010. 255. rrr  Symbolics,  Inc.  [OH2] 

192. Oil. 255. rrr  ATT.  Bell  Labs  [Fiu2] 
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C*192.012.000.rrr  CADMUS -ETHERNET  CADMUS -NET  [MS9] 
C*192.012.001.rrr  CADMUS-EXP-1  CADMUS -NET- EXP -1  [MS9] 
C*192.012.002.rrr  CADMUS-EXP-2  CADMUS-NET-EXP-2  [MS9] 
C*192 .012 .003.rrr  FLAIR  Fairchild  AI  Lab  Net  [128,AMS1] 
C*192.012.004.rrr  SCG-NET  Hughes  SCG  Net  [122, MXP] 
R  192. 012. 005. rrr  AIC-LISPMS  SRI-AIC-LispMachNet  [128, PM4] 
R  192. 012. 006. rrr  NPS-C2  NPS-C2  [128, AW9] 
R  192. 012. 007. rrr  NYU-CS-EIHER  NYU  CompSci  Ethernet  [128, LOU] 
D  192. 012. 008. rrr  PICANETl  Picatinny  Arsenal  LANl  [128,RFD1] 
R  192. 012. 009. rrr  CADRE-NET  Decision  Systems  Lab  [SM6] 
R  192. 012. 010. rrr  CORNELL-ENG  Cornell -Engineering  [128, BN9] 
R  192. 012. oil. rrr  MIT-TEST  MIT  Gateway  TEST  NET  [128, NC3] 
R  192. 012. 012. rrr  WISC-ETHER  Wisconsin  Ether  N^^t  [1^8, CBP] 
R  192. 012. 013. rrr  JHU-NETl  JHU-NETl  [12-,M014] 
R  192. Q 12. 014. rrr  JHU-NET2  JHU-NET2  [128,M014] 
R  192. 012. 015. rrr  BROOKNET  BNL  Brooknet  III  [128, GC] 
R  192. 012. 016. rrr  PRMNET  SRI-SURAN-EN  [128,BP17] 
G  192. 012. 017. rrr  LLL-TIS-NET  LLL-TIS-NET  [119, 123,GP10] 
R  192. 012. 018. rrr  CIT-CS-IONET  Caltech  lOMeg  EtherNet [126, AD22] 
R  192. 012. 019. rrr  CIT-NET  Caltech  Campus  Net  [126,AD22] 
R  192. 012. 020. rrr  CIT-SUN-NET  Caltech  Sun  Net  [126,AD22] 
R  192. 012. 021. rrr  CIT-PHYSCOMP  Caltech  Phys  Conp  Net  [126,AD22] 
R  192. 012. 022. rrr  UTCSRES  UTCS  Net  Research  [128,JSQ1] 
R  192. 012. 023. rrr  UTCSTTY  UTCS  TTY  Kludgenet  [128,JSQ1] 
R  192. 012. 024. rrr  MICANET  MIIRE  (Ejqperimental)  [WDL] 
R  192. 012. 025. rrr  CSS-GRAMINAE  CSS  Workstation  Net  [62,RR2] 
R  192. 012. 026. rrr  NOSC-NETR  Net-R  Testbed  at  BBN  [106,CP103 
R  192. 012. 027. rrr  UR-LASER  UR  Laser  Energetics  [128, WXL] 
R* 192. 012. 028. rrr  RIACS-X-NET  RIACS-Ejqpcrimental-Net  [DG28] 
D  192.012.029-rrr  PJF-EVANS  ADDCOMPE  DC3  LANl  [120,MB31] 
D  192. 012. 030. rrr  RF-HEX-A  ADDCOMPE  DC3  LAN2  [120,MB31] 
D  192. 012. 031. rrr  USNA-ENET  USNA  Engineering  Net  [120, TXS] 
R*192.012.032.rrr  CMU-VINEYARD  CMU  File  Cluster  Net  [128, MXK] 
R  192. 012. 033. rrr  5RI-CSL-NET  SRI-CSL  10MB  Ethernet  [GEOF] 
C*192  012.034.rrr-192.012.043.rrr  Schluraberger  PA  Net  [128, RXB] 
R  192. 012. 044. rrr  NRTC-NET  Northrop  Research  Net  [128,RSM1] 
R  192. 012. 045. rrr  ACC-SB-IMP-NTf  ACC  Santa  Barbara  IMP  [AB20] 
R  192. 012. 046. rrr  ACC- SB- ETHER  ACC  Santa  Barbara  Ethernet [AB20] 
R  192. 012. 047. rrr  UMN-UCC-NET  Univ.  of  Minnesota  [RG12] 
G  192. 012. 048. rrr  AMES-ED-EXPNET  Code  ED  Exp.  Net.  [128,MSM1] 
G  192. 01 2. 049. rrr  AMES-ED-NET  Code  ED  IP  Net  [128,MSM1] 
C  192. 012. 050. rrr  AMES-DB-NET  Ames  DBridge  Net  [128.MSM1] 
R  192. 012. 051. rrr  THINK-CHAOS  H^C  Chaos  [128,BJN1] 
R* 192. 012. 052. rrr  NEURO-NET  NEURO-NET  [128, JXB] 
R*192.012.053.rrr  PU-LCA  Princeton  U.  LCA  [128, CXH] 
R  192. 012. 054. rrr  WISC-MADISON  Univ  Wise  -  MACC  [128, JXD] 
R  192. 012. 055. rrr  HAZ-LPR-BETA  Hazeltine  LPR  Net  [128. KXK] 
R  192. 012. 056. rrr  UTAH-AP-NET  Otah-Appolo-Ring-Net  [JLlSj 
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R  192. 012. 057. rrr 

MCC-CAD-NET 

MCC  AI  Subnet 

[128, CBD] 

R  192. 012. 058. rrr 

MCC-PP-NET 

MCC  CAD  Subnet 

[128, CBD] 

R  192. 012. 059. rrr 

MCC-DB-NET 

MCC  DB  Subnet 

[128, CBD] 

R  192. 012. 060. rrr 

MCC-HI-'NET 

MCC  HI  Subnet 

[128, CBD] 

R  192. 012. 061. rrr 

MCC-SW-NET 

MCC  SW  Subnet 

[128, CBD] 

R  192. 012. 062. rrr 

DREA-ENET 

DRE.A  Lispm  &  Vaxen 

[128,GLH5] 

R  192. 012. 063. rrr 

CYPRESS 

CYPRESS  Serial  Net 

[CAK] 

D  192. 012. 064. rrr 

LOOTET 

Logistics  Net  GW 

[62,JXR] 

D  192. 012. 065. rrr 

HELNETl 

HELNETl 

[128,MJM21 

D  192. 012. 066. rrr 

HELNET2 

HELNET2 

[128,MJM2] 

D  192. 012. 067. rrr 

HELNET3 

HELNET3 

[MsJM2] 

G  192. 012. 068. rrr 

ORNL-MSRNET 

ORNL  Local  Area  Net 

[62, HD] 

R  192. 012. 069. rrr 

UA-CS-NET 

UNIV.  OF  ARIZ-CS  DEPT 

[128, BXM] 

R  192. 012. 070. rrr 

NPRDC-IPD 

NPRDC-IPD  REMOTE  ETHERNET  [LRB] 

R  192. 012. 071. rrr 

NPRDC-ISG 

NPRDC-ISG  REMOTE  ETHERNET  [LRB] 

R  192. 012. 072. rrr 

ULCC 

UK. AC. ULCC 

[RHC3] 

R  192. 012. 073. rrr 

BTRL 

UK .  CO .  BT-RESEARCH-LABS 

[RHC3] 

R*192,012.074.rrr 

APPLE-ETHER 

APPLE  COMPUTER  ETHER 

[128, RXJ] 

R*192.012.075.rrr 

PASC-RING 

IBM  PASC  TOKEN  RING 

[GXL] 

R*192.012.076.rrr 

UQ-NET 

UNIV.  OF  QLD  NETWORK 

[128, AXH] 

C*192.012.077.rrr 

PRIME 

PRIME  COMPUTER,  INC. 

[FXS] 

0*192.012.078. rrr 

GENNET 

GENENTECH  NET 

[128, SXM] 

0*192.012. 079. rrr 

SLI 

SOFTWARE  LEVERAGE  INC. 

[MXG] 

R  192. 012. 080. rrr 

CAEN 

UMICH-CAEN 

[HWB] 

R  192. 012. 081. rrr 

YALE-RING-NET 

YALE  RESEARCH  RING 

[RC77] 

0  192. 012. 082. rrr 

CU-CC-NET 

Columbia  CC  Net 

[128,BC14] 

0*192.012.083. rrr 

UCDLA-EXNET 

UCDLA  EXPERIMENTAL  NET 

[CXL] 

0*192.012. 084. rrr 

UCDLA-PCNET 

UCDLA  PERSONAL  NET 

[OOL] 

0*192. 012. 085. rrr 

UCDLA-OPNET 

UCDLA  OPTICAL  DISK 

[CXL] 

0*192. 012. 086, rrr 

UCDLA-RADNET 

UCDLA  PACKET  RADIO 

rcxL] 

0*192. 012. 087. rrr 

UCDLA-CSLNET 

UCDLA  STATE  LIBRARY 

[CXL] 

R*  192. 012. 088. rrr 

RUTGERS-NWK 

RUTGERS,  NEWARK 

[DXB] 

R  192. 012. 089. rrr 

SBCS-CSDEPT-1 

SB  Conputer  Science 

[JXS] 

R  192. 012. 090. rrr 

SBCS-CSDEPT-2 

SB  Computer  Science 

[JXS] 

R*192.012.091.rrr 

RPICSNETO 

RPICS-LOCALNET-0 

LMS9] 

R*192.012.092.rrr 

RPICSNETl 

RPICS-LOCALNET-1 

[MS9] 

R*192.012.093.rrr 

RPICSNET2 

RPICS-LOCALNET-2 

[MS9] 

R*192.012  094. rrr 

RPICSNET3 

RPICS-LOCALNET-3 

[MS9] 

R*192.012.095.rrr 

RPICSNET4 

RPICS-LOCALNET-4 

[MS9] 

R*192.012.096.rrr 

RPICSNET5 

RPICS-LOCALNET-5 

[MS9] 

R*192.012.097.rrr 

RPICSNET6 

RPICS-LOCALNET-6 

[MS9] 

R*192.012.098.rrr 

RPICSNET7 

RPICS-LOCALNET-7 

[MS9] 

R*192.012.099.rrr 

RPICSNET8 

RPICS-LOCALNET-8 

[MS9] 

R*192.012.100.rrr 

RPICSNET9 

rpics-loc:alnet-9 

[MS9] 

R*192.012.101.rrr 

OSU-CGRC 

OSU  Conputer  Graphics 

[128, KXS] 

G  192.012. 102. rrr 

AMES-NAS-HY 

AMES  NAS  HY  NET 

[MF31] 

R*192.012.103  rrr- 

192. 012. 118. rrr 

Colorado  State  Univ  Nets  [RXBl] 

G  192. 012. 119. rrr 

ICST 

ICST  Network 

[128.  J‘,  .] 
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Network  Numbers 


[BSW] 

1  [TXB] 

2  [TXB] 
[128,MSM1] 

[128, WWS] 
[128, JXY] 
[128,  JXY] 
[128,  GAA] 
[128, DVC] 
[MXH] 
[CAS] 
[128,KMC3] 
[128, BANDY] 
[128,  BANDY] 
[128, BANDY] 
[128, BANDY] 
[128, BANDY] 
[128, BANDY] 
[128,  BANDY] 
[RR26] 
[DXT] 
!  [RAll] 

:  [LXL] 

[LXL] 
[128, PXD] 

C*192.012.145  rrr-192.012.154.rrr  RCA-CADNET  [128, RXG] 


C*192.012.155  rrr-192.012.170.rrr  MTCS-CUST  [SXF] 

D  192.012.171.rrr  PICANET2  Plcatlnny  Arsenal  2  [RFDl] 

R  192. 012. 172. rrr  RCX:KWELLENET  ROCKWELL  ETHERNET  [NG] 

D  192. 012. 173. rrr  JTELS-BENl-GW  JUMPS  Teleprocessing  [RR26] 

R*192.012.174  rrr-192.012.183.rrr  TORONTO  [128, BXD] 

192.012.184  rrr-192.012.255.rrr  Unasslgned  [JBP] 

D  192.013.000.rrr-192.014.255.rrr  DODIIS  Subnetworks  [AY5] 

C*192.015.000.rrr-192,015.255.rrr  NBINET  [WW2] 

G  192.016.000.rrr-192.016.049.rrr  LANLLAN  [128,JC11] 

192.016.050.rrr-192.016.255.rrr  Unassigned  [JBPl 

R* 192 . 017 . 000 . rrr- 192 . 017 . 255 . rrr  NIBELUNG  [MXA] 

C*192.018.000.rrr-192.018.255.rrr  SUN  Microsystems,  Inc.  [BN4] 

C*192.019.000.rrr-192.019.255.rrr  SYSNET-2  [EXY] 

C*192.020.000.rrr-192.020.255.rrr  ATT-MD-NET  [128,MH12] 

192.021.000.rrr-223.255.254.rrr  Unassigned  ['JBP] 

223. 255. 255. rrr  Reserved  [JBP] 


D  192. 012. 120. rrr  MITRE-B-NET 
R* 192.012.121. rrr  FSUCS 

R*192 . 012 . 122 .rrr  FSUCS2 

G  192. 012. 123. rrr  AMES-CCF-NET 

19  !. 012. 124. rrr  ETL-LAN 

192 . 012 . 125 . rrr  CRDC-NETl 

192. 012. 126. rrr  CRDC-NET2 

192.012.127. rrr  LL-MI -NET 

192 . 012 . 128 . rrr  AITAC -ADMIN 

C* 192.012.129. rrr  SYM-CAN 

R  192. 012. 130. rrr  SDC-SM 

192 .012.131. rrr  SAC -ADMIN 
192 .012.132. rrr  LLL-MON 
192. 012. 133. rrr  LLL-TUES 
192 . 012 . 134 . rrr  LIL-WED 
192. 012. 135. rrr  LLL-THU 
192. 012. 136. rrr  LLL-FRI 
192 . 012 . 137 . rrr  LLL-SAT 
192.012.138. rrr  LLL-SUN 
192 . 012 . 139 . rrr  JTELS-BEN-GW 

R*192.012.14C.rrr  INFERENCE 
R  192. 012. 141. rrr  CSS-ETHER 
C* 192 . 012 . 142 . rrr  SENTRY 
C*192 . 012 . 143 . rrr  VHSIC-NET 

R*192 . 012 . 144 . rrr  ECRCNET 


D 

D 

D 

R 

R 


R 

R 

R 

R 

R 

R 

R 

R 

D 


MITRE  BEDFORD  ETHER 
FSU  COMPUTER  SCIENCE 
FSU  COMPUTER  SCIENCE 
AMES  CCF  NETWORK 
ETL  LOCAL  AREA  NET 
CRDC-NETl 
CRDC-NET2 
LL-Machine  Intel 1. 

SRI -AITAC  ADMIN  NET 
Symbolics/Canada 
SDC  Santa  Monica 
SRI -SAC  ADMIN  NET 
LLL  Open  Labnet-1 
LLL  Open  Labnet-2 
LLL  Open  Labnet-3 
LLL  Open  Labnet-4 
LLL  C^en  Labnet-5 
LLL  Open  Labnet-6 
LLL  C^n  Labnet-7 
JUMPS  Teleprocessing 
INFERENCE 

CSS  Workstation  Net 
Sentry  Adv.  Prod.  Ne' 
Sentry  VHSIC  Test 
ECRC  Internet 
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Assigned  Numbers 
Network  Numbers 


Network  Totals 

Assigned  for  the  ARPA- Internet  and  the  DDN- Internet 


RFC  960 


Class 

A 

B 

C 

Total 

Research 

7 

63 

911 

981 

Defense 

8 

15 

536 

559 

Government 

0 

2 

59 

61 

Commercial 

2 

1 

4 

7 

Total 

17 

81 

1510 

1608 

located  for 

Internet 

and  Independent  Uses 

Class 

A 

B 

C 

Total 

Research 

7 

68 

1764 

1838 

Defense 

8 

15 

536 

559 

Government 

1 

3 

64 

68 

Commercial 

2 

5 

2357 

2364 

Total 

18 

91 

4721 

4829 

ximum  Allowed 

Class 

A 

B 

C 

Total 

Research 

8 

1024 

65536 

66568 

Defense 

24 

3072 

458752 

461848 

Government 

24 

3072 

458752 

461848 

Commercial 

74 

9214 

1114137 

1123394 

Total 

126 

16382 

2097150 

2113658 
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Assigned  Numbers 

RFC  960 

Protocol  Numbers 

1 

ASSiartD  PROTOCOL  NUMBERS 

In  the  Internet  Protocol 

(IP)  [39,92]  there  is  a  field,  called 

Protocol ,  to 

identify  the 

the  next  level  protocol .  This 

is  an  8  bit  W 

field. 

Assigned  Internet  Protocol  Numbers 

Decimal 

Keyword 

Protocol 

References  y 

>  . 

0 

Reserved 

[^BP]  i 

1 

ICMP 

Internet  Control  Message 

[84,JBP]  ? 

2 

Unassigned 

[JBP] 

3 

CCP 

Gateway- to -Gateway 

[51,  MB] 

4 

Unassigned 

[JBP] 

5 

ST 

Stream 

[43,JWF] 

6 

TCP 

Transmission  Control 

[39, 93, JBP] 

7 

UCL 

UCL 

[PK]  || 

8 

EGP 

Exterior  Gateway  Protocol 

[108,DLM1]  ^ 

9 

IGP 

any  private  interior  gateway 

[JBP] 

10 

BBN-RCC-MON 

BBN  RCC  Monitoring 

[SGC] 

11 

NVP-II 

Network  Voice  Protocol 

[21,SC3] 

12 

PUP 

PUP 

[15,HGM] 

13 

ARGUS 

ARGUS 

[RWS4] 

14 

EMCON 

EMCON 

[BN7]  JjjJ 

15 

XNET 

Cross  Net  Debugger 

[49,JFH2]  H 

16 

CHAOS 

Chaos 

[NC3] 

17 

UDP 

User  Datagram 

139,91, JBP] 

18 

MUX 

Multiplexing 

[22,  JBP]  ;•/ 

19 

DCN-MEAS 

DCN  Measurement  Subsystems 

[DLMl]  i.*'. 

20 

HMP 

Host  Monitoring 

[6,RH6] 

21 

PRM 

Packet  Radio  Measurement 

[ZSU]  V 

22 

XNS-IDP 

XEROX  NS  IDP 

[129, LLG]  m 

23 

TRUNK-1 

Trunk- 1 

[SA2] 

24 

TRUNK- 2 

Trunk- 2 

[SA2] 

25 

LEAF-1 

Leaf-1 

[SA2] 

26 

LEAF-2 

Leaf-2 

[SA2] 

27 

RDP 

Reliable  Data  Protocol 

[125, RH6] 

28 

IRTP 

Internet  Reliable  Transaction 

[68,TXM] 

29 

IS0-TP4 

ISO  Transport  Protocol  Class  4 

[57,RC7]  m 

30-60 

Unassigned 

[JBP]  P 

61 

any  host  internal  protocol 

[JBP]  v; 

62 

CFTP 

CFTP 

[44.HCF2]  V 

63 

any  local  network 

[JBP] 

64 

SAT-EXPAK 

SATNET  and  Backroom  EXPAK 

[SHB]  V*. 

65 

MIT-SUBNET 

MIT  Subnet  Support 

[NC3]  S- 

66 

RVD 

MTT  R«mote  Virtual  Disk  Protocol  rMBGl  t  • 

67 

IPPC 

Internet  Pluribus  Packet  Core 

[SHB]  P 

Reynolds  &  Postel 
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ol  Numbers 

68 

any  distributed  file  system 

[JBP] 

69 

SAT-MON 

SATNET  Monitoring 

[SHB] 

70 

Unassigned 

[JBP] 

71 

IPCV 

Internet  Packet  Core  Utility 

[SHB] 

72-75 

Unassigned 

[JBP] 

76 

BR-SAT-MON 

Backroom  SATNET  Monitoring 

[SHB] 

77 

Unassigned 

[JBP] 

78 

WB-MON 

WIDEBAND  Monitoring 

[SHB] 

79 

WB-EXPAK 

WIDEBAND  EXPAK 

[SHB] 

80-254 

Unassigned 

[JBP] 

255 

Reserved 

[JBP] 

Reynolds  &.  Postel 
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Assigned  Numbers  RFC  960 

Port  Numbers 


ASSIGNED  PORT  NUMBERS 

Ports  are  used  in  the  TCP  [39,93]  to  name  the  ends  of  logical 
connections  which  carry  long  term  conversations.  For  the  purpose  of 
providing  ser'/ices  to  unknown  callers,  a  service  contact  port  is 
defined.  This  list  specifies  the  port  used  by  the  server  process  as 
its  contact  port.  The  contact  port  is  sometimes  called  the 
"well-known  port". 

To  the  extent  possible,  these  same  port  assignments  are  used  with  the 
UDP  [39,91]. 

To  the  extent  possible,  these  same  port  assignments  are  used  with  the 
IS0-TP4  [57] . 

The  assigned  ports  use  a  small  portion  of  the  possible  port  numbers. 
The  assigned  ports  have  all  except  the  low  order  eight  bits  cleared 
to  zero.  The  low  order  ei^t  bits  are  specified  here. 

Port  Assignments: 


Decimal 

Keyword 

Description 

References 

0 

Reserved 

[JBP] 

1-4 

Unassigned 

[JBP] 

5 

RJE 

Remote  Job  Entry 

[17, 40, JBP] 

7 

ECHO 

Echo 

[82, JBP] 

9 

DISCARD 

Discard 

[80, JBP] 

11 

USERS 

Active  Users 

[76, JBP] 

13 

DAYTIME 

Daytime 

[79, JBP] 

15 

NETSTAT 

Who  is  up  or  NETSTAT 

[JBP] 

17 

QUOTE 

Quote  of  the  Day 

[87, JBP] 

19 

CHARGEN 

Character  Generator 

[78, JBP] 

20 

FTP-DATA 

File  Transfer  [Default  Data] 

[39,83, JBP] 

21 

FTP 

File  Transfer  [Control] 

[39,  83, JBP] 

23 

TELNET 

Telnet 

[99, JBP] 

25 

SMTP 

Simple  Mail  Transfer 

[39,89, JBP] 

27 

NSV»-FE 

NSW  User  System  FE 

[23,RHr] 

29 

MSG-ICP 

MSG  ICP 

r74,RHr] 

31 

MSG-AUTO 

MSG  Authentication 

[74,RHr] 

33 

DSP 

Dis*play  Support  Protocol 

[MLC] 

35 

any  private  printer  server 

[JBP] 

37 

TIME 

Time 

[95, JBP] 

39 

RLP 

Resource  Location  Protocol 

[l.MAl 

41 

GRAPHICS 

Graphics 

[40. 115, JBP] 
[39.86. JBP] 

42 

NAMESERVER 

Host  Name  Server 

43 

NICNAME 

Who  Is 

[39.48. JAKE] 

44 

MPM-FLAGS 

MPM  FLAGS  Protocol 

[JBP] 

Ids  &  Postel 
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45 

MPM 

Message  Processing  Module  [recv] 

[85.JBP] 

46 

MPM-SND 

MPM  [default  send] 

[91.JBP] 

47 

NI-FTP 

NI  FTP 

[122. SK] 

49 

LOGIN 

Login  Host  Protocol 

[PHDl] 

51 

LA-MAINT 

IMP  Logical  Address  Maintenance 

[66,AGM] 

53 

DOMAIN 

Domain  Name  Server 

[81,71,PM1] 

55 

ISI-GL 

I SI  Graphics  Language 

[14,RB6] 

57 

any  private  terminal  access 

[JBP] 

59 

any  private  file  service 

[JBP] 

61 

NI-MAIL 

NI  MAIL 

[12,  SK] 

63 

VIA-FTP 

VIA  Systems  -  FTP 

[DXD] 

65 

TACACS-DS 

TACACS -Database  Service 

[ll.RHT] 

67 

BOOTPS 

Bootstrap  Protocol  Server 

[35,WJC2] 

68 

BOOTPC 

Bootstrap  Protocol  Client 

[35,WJC2] 

69 

TFTP 

Trivial  File  Transfer 

[39,102,DDC1] 

VI 

NETRJS-1 

Remote  Job  Service 

[16,40,RTB] 

72 

NETRJS-2 

Remote  Job  Service 

[16,40,RTB] 

73 

NEmJS-3 

Remote  Job  Service 

[16.40,RTB] 

74 

NETRJS-4 

Remote  Job  Service 

[16,40,RTB] 

75 

any  private  dial  out  service 

[JBP] 

77 

any  private  RJE  service 

[JBP] 

79 

FINGER 

Finger 

[40.46.KLH] 

81 

H0STS2-NS 

H0STS2  Name  Server 

[EAKl] 

83 

MIT-ML-DEV 

MIT  ML  Device 

[DPR] 

85 

MIT-ML-DEV  MIT  ML  Device 

[DPR] 

87 

any  private  terminal  link 

[JBP] 

89 

SU-MIT-TG 

SU/MIT  Telnet  Gateway 

[MRC] 

91 

MIT-DOV 

MIT  Dover  Spooler 

[EBM] 

93 

DCP 

Device  Control  Protocol 

[DT15] 

95 

SUPDUP 

SUPDUP 

[26, MRC] 

97 

SWIFT-RVF 

Swift  Remote  Vitural  File  Protocol  [MXR] 

98 

TACNEWS 

TAC  News 

[FRAN] 

99 

METAGRAM 

Metagram  Relay 

[GEOF] 

101 

HOSTNAME 

NIC  Host  Name  Server 

[39, 47, JAKE] 

103 

Unassigned 

[JBP] 

105 

CSNET-NS 

Mailbox  Name  Nameserver 

[113.MHS1] 

107 

RTELNET 

Remote  Telnet  Service 

[88. JBP] 

109 

POP -2 

Post  Office  Protocol  -  Version  2 

[19.JKR1] 

111 

SUNRPC 

SUN  Remote  Procedure  Call 

[DXG] 

113 

AUTO 

Authentication  Service 

[116,MCSJ] 

115 

SFTP 

Slnple  File  Transfer  Protocol 

[60.MKL1] 

117 

UUCP-PATO 

UUCP  Path  Service 

[38. MAE] 

119 

UNTP 

USENET  News  Transfer  Protocol 

[61.PL4] 

121 

ERPC 

HYDRA  Expedited  Remote  Procedure 

Call [118, JXO] 

123 

NIP 

Network  Time  Protocol 

[70.DLM1] 

125 

LOCUS-MAP 

Locus  PC- Inter face  Net  Map  Server  [124. BXG] 

127 

LOCUS-CON 

Locus  PC- Inter face  Conn  Server 

[124. BXG] 

129 

Unassigned 

[JBP] 

Reynolds  &  Postel 


[Page  19] 


APPENDIX 


RFC  960 


Assigned  Numbers  RFC  960 

Autonomous  System  Numbers 


ASSIGNED  AUTWOMOUS  SYSTEM  NUMBERS 

The  Exterior  Gateway  Protocol  (EGP)  [108,105]  specifies  that  groups 
of  gateways  may  form  autonomous  systems.  The  EGP  provides  a  16 -bit 
field  for  identifying  such  systems.  The  values  of  this  field  are 
registered  here. 


Autonomous  System  Numbers: 


Decimal  Name 


References 


0  Reserved 

1  The  BBN  Core  Gateways 

2  DCN-AS 

3  The  MIT  Gateways 

4  ISI-AS 

5  Symbolics 

6  HIS-Multics 

7  UK-MOD 

8  RICE-AS 

9  OMU-ROUTER 

10  CSNET-PDN-AS 

11  HARVARD 

12  NYU-DOMAIN 

13  BRL-AS 

14  COLUMBIA-GW 

15  NET  DYNAMICS  EXP 

16  LBL 

17  PURDUE-CS 

18  UTEXAS 

19  CSS-DOMAIN 

20  UR 

21  RAND 

22  NOSC 

23  RIACS-AS 

24  AMES-NAS-GW 

25  UCB 

26  CORNELL 

27  UMDNET 

28  DFVLR-SYS 

29  YALE-AS 

30  SRI-AICNET 

31  CIT-CS 

32  STANFORD 

33  DEC-WRL-AS 

34  UDEL-EECIS 

35  MICATON 

36  ECP-TESTOR 


[JBP] 

[MB] 

[DLMl] 

[LM8] 

[JKRl] 

[CH2] 

[BIM.JLM23] 

[RNMl] 

[PGM] 

[MA] 

[RDR4] 

[SB28] 

CEF5] 

[RBNl] 

[BC14] 

[ZSU] 

[WC] 

[KCSl] 

[JSQl] 

[RR2] 

[LB16] 

[JDG] 

[RLB3] 

[DG28] 

[MF31] 

[MK17] 

[BN9] 

[JWOl] 

[HDCl] 

[JG46] 

[PM4] 

[AD22] 

[PA5] 

[RKJ2] 

[NW] 

[WDL] 

CBPi7] 
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37 

NSWC 

38 

UIUC 

39 

NRL-ITD 

40 

MIT-TEST 

41 

AMES 

42 

THINK-AS 

43 

BNL-AS 

44 

SI-DOMAIN 

45 

LLL-TIS-AS 

46 

RUTCERS 

47 

USC-OBERON 

48 

NRL-AS 

4J 

ICST-AS 

50 

ORNL-MSRNET 

51 

USAREUR-EM-AS 

52 

UCLA 

53-65534 

Unassigned 

65535 

Reserved 

[MXPl] 

[AKC] 

CAP] 

[NC3] 

[MSMl] 

[BJNl] 

[CC] 

[LWR] 

[GPIO] 

[RMS] 

[DRS4] 

CWF3] 

CJCN2] 

[THD] 

[WXD] 

[BXL] 

[JBP] 

[JBP] 
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Domain  System  Parameters 


RFC  960 


DOMAIN  SYSTEM  PARAMETERS 

The  Internet  Domain  Naming  System  (DOMAIN)  includes  several 
parameters.  These  are  documented  in  RFC  883  [72]  .  The  CLASS 
parameter  is  listed  here.  The  per  CLASS  parameters  are  defined  in 
separate  RFCs  as  indicated. 


Domain  System  Parameters: 
Decimal  Name 


0  Reserved 

1  Internet 

2  Unassigned 

3  Chaos 

4<65534  Unassigned 
65535  Reserved 


Referc^nces 

[PMl] 

[72,PM1] 

[PMl] 

[PMl] 

[PMl] 

[PMl] 
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ARPANET  Logical  Addresses 


ASSIGNED  ARPANET  LOGICAL  ADDRESSES 

The  ARPANET  facility  for  "logical  addressing"  is  described  in 
RFC  878  [65] .  A  portion  of  the  possible  logical  addresses  are 
reserved  for  standard  uses. 


There  are  49,152  possible  logical  host  addresses.  Of  these,  256  are 
reserved  for  assignment  to  well-known  functions.  Assignments  for 
well-known  functions  are  made  by  Joyce  Reynolds.  Assignments  for 
other  logical  host  addresses  are  made  by  the  NIC. 


Logical  Address  Assignments: 


Decimal  Description 


0  Reserved 

1  The  3BN  Core  Gateways 

2-255  Unassigned 

256  Reserved 


References 


[JBP] 

[MD] 

[JBP] 

[JBP] 
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RFC  960 


ASSIGNED  ARPANET  LINK  NUMBERS 

The  word  "link"  here  refers  to  a  field  in  the  original  ARPANET 
Host/IMP  interface  leader.  The  link  was  originally  defined  as  an 
8-bit  field.  Later  specifications  defined  this  field  as  the 
"message-id"  with  a  length  of  12  bits.  The  name  link  now  refers  to 
the  high  order  8  bits  of  this  12-bit  message-id  field.  The  Host/IMP 
interface  is  defined  in  BBN  Report  1822  [10] . 

The  low- order  4  bits  of  the  message- id  field  are  called  the  si±>-link. 
Unless  explicitly  specified  otherwise  for  a  particular  protocol, 
there  is  no  sender  to  receiver  significance  to  the  sub- link.  The 
sender  may  use  the  sub- link  in  any  way  he  chooses  (it  is  returned  in 
the  RFNM  by  the  destination  IMP) ,  the  recei  ver  should  ignore  the 
sub-lirik. 


Link  Assignments: 

Decimal  Description 


0 

1-149 

150 

151 


155 

156-158 

159 

160-194 

195 

196-247 

248-255 


Reserved 
Unas.signed 
Xerox  NS  IDP 
Unass i gncd 

PARC  universal  Protocol 
TIP  Status  Reporting 


XXX  tCXi  IV. 


Internet  Protocol  [regular] 
Internet  Protocol  [experimental] 
Figleaf  Link 
Unassigned 
I SO- IP 

Experimental  Protocols 
Network  Maintenance 


References 

[JBP] 
[JBP] 
[129,  LLG] 
[JBP] 
[15,HGM] 
[JGH] 
[JC3I] 
[39,  92, JBP] 
[39, 92, JBP] 
[JBWl] 
[JBP] 
[58,RXM] 
[JBP] 
[JC3i] 
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IEEE  802  SAP  Numbers 


IEEE  802  SAP  NUMBERS  OF  INTEREST 

Some  of  the  networks  of  all  classes  are  IEEE  802  Networks.  These 
systems  may  use  a  Service  Access  Point  field  in  much  tlie  same  way  the 
ARPANET  uses  the  "link”  field.  For  further  information  and  SAP 
number  assignments,  please  contact:  Mr.  Maris  Graube,  Chairman,  IEEE 
802,  Route  1,  244  H,  Forest  Grove,  Oregon,  97116. 

Assignments : 

Service  Access  Point  Description  References 


decimal  binary 

127  01111111  ISO  DIS  8473  [JXJ] 

96  01100000  DOD  IP  [39,91,JBP] 

The  IEEE  802.3  header  does  not  have  a  type  field  to  indicate  what 
protocol  is  used  at  the  next  level.  As  a  work  around  for  this 
problem,  one  can  put  the  Ethernet  type  field  value  in  the  IEEE  802.3 
header's  length  field  and  use  the  following  test  to  determine  the 
af^ropriate  processing  on  receipt. 

If  the  value  in  the  length  field  of  the  IEEE  802.3  header  is  greater 
than  the  Ethernet  maximum  packet  length,  then  interpret  the  value  as 
an  Ethernet  type  field.  Otherwise,  interpret  the  packet  as  an  IEEE 
802.3  packet. 

The  proposed  standard  for  transmission  of  IP  datagrams  over  IEEE 
802.3  networks  is  specified  in  RFC  948  [127] . 
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Ethernet  Numbers 


ETHERNET  NUMBERS  OE*  INTEREST 

Many  of  the  networks  of  all  classes  are  Ethernets  (10Mb)  or 
Experimental  Ethernets  (3Mb)  .  These  systems  use  a  message  "type" 
field  in  much  the  same  way  the  ARPANET  uses  the  "link"  field. 

If  you  need  an  Ethernet  number,  contact  the  XEROX  Corporation,  Office 
Products  Division,  Network  Systenas  Administration  Office,  333  Coyote 
Hill  Road,  Palo  Alto,  California,  94304 

Assignments : 


Ethernet 

Exp .  Ethernet 

Description 

References 

decimal 

Hex 

decimal 

octal 

512 

0200 

512 

1000 

XEROX  PUP 

[1,HGM] 

513 

0201 

- 

PUP  Addr.  Trans. 

[HGM] 

1536 

0600 

1536 

3000 

XEROX  NS  IDP 

[128,  HGM] 

2048 

0800 

513 

1001 

DOD  IP 

[39,91,JBP] 

2049 

0801 

- 

- 

X.75  Internet 

[HGM] 

2050 

0802 

- 

- 

NBS  Internet 

[HGM] 

2051 

0803 

- 

- 

ECMA  Internet 

[HGM] 

2052 

0804 

- 

- 

Chaosnet 

[HGM] 

2053 

0805 

- 

- 

X.25  Level  3 

[HGM] 

2054 

0806 

- 

- 

ARP 

[74,JBP] 

2055 

0807 

- 

- 

XNS  Conpatability 

[HGM] 

2076 

081C 

- 

- 

Symbolics  Private 

[DCPl] 

32771 

8003 

- 

- 

Cronus  VLN 

[116,DT15] 

32772 

8004 

- 

- 

Cronus  Direct 

[116,DT15] 

32774 

8006 

- 

- 

Nestar 

[HGM] 

32784 

8010 

- 

- 

Excel an 

[HGM] 

32821 

8035 

- 

- 

Reverse  ARP 

[42,JCM] 

36864 

9000 

- 

- 

Loopback 

[HGM] 

The  standard  for  transmission  of  IP  datagrams  over  Ethernets  and 
Experimental  Ethfimets  is  specified  in  RFC  894  [54]  and  RFC  895  [76] 
respectively . 
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RFC  960 


ASSIGNED  ADDRESS  RESOLUTION  PROTOCOL  PARAMETERS 

Hie  Address  Resolution  Protocol  (ARP)  specified  in  RFC  826  [75]  has 
several  parameters.  The  assigned  values  for  these  parameters  are 
listed  here. 

Assignments : 

Operation  Code  (op) 

1  REQUEST 

2  REPLY 

Hardware  Type  (hrd) 

Type  Description  References 

1  Ethernet  (10Mb)  [JBP] 

2  Experimental  Ethernet  (3Mb)  ['JBP] 

3  AmotavU^  Radio  AX .  25  [PXEC] 

4  Proton  ProNET  Token  Ring  ['JBP] 

5  Chaos  [GXP] 

Protocol  Type  (pro) 

Use  tlie  same  codes  as  listed  in  the  section  called  "Ethernet 
Numbers  of  Interest"  (all  hardware  types  use  this  code  set  for 
the  protocol  type)  . 
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ASSIGNED  PUBLIC  DATA  NETWORK  NUMBERS 

One  of  the  Internet  Class  A  Networks  is  the  international  system  of 
Public  Data  Networks.  This  section  lists  the  mapping  between  the 
Internet  Addresses  and  the  Public  Data  Network  Addresses  (X.121)  . 

Assignments : 


Internet 

Public  Data  Net 

Description 

References 

014.000.000.000 

Reserved 

[JBP] 

014.000.000.001 

3110-317-00035 

00 

PURDUE-TN 

[CAK] 

014.000.000.002 

3110-608-00027 

00 

UWISC-TN 

[CAK] 

014.000.000.003 

3110-302-00024 

00 

UDEL-TN 

[CAK] 

014.000.000.004 

2342-192-00149 

23 

UCL-VTEST 

[PK] 

014.000.000.005 

2342-192-00300 

23 

UCL-TO 

[PK] 

014.000.000.006 

2342-192-00300 

25 

UK-SATNET 

[PK] 

014.000.000.007 

3110-608-00024 

00 

UWISC-IBM 

[MHSl] 

014.000.000.008 

3110-213-00045 

00 

RAiro-TN 

[M02] 

014.000.000.009 

2342-192-00300 

23 

UCL-CS 

[PK] 

014.000.000.010 

3110-617-00025 

00 

BBN-VAN-GW 

[JD21] 

014.000.000.011 

2405-015-50300 

00 

CHALMERS 

[UXB] 

014.000.000.012 

3110-713-00165 

00 

RICE 

[PAM6] 

014.000.000.013 

3110-415-00261 

00 

DECWRL 

[PAM6] 

014.000.000.014 

3110-408-00051 

00 

IBM-SJ 

['SAl] 

014.000.000.015 

2041-117-01000 

00 

SHAPE 

[JFW] 

014.000.000.016 

2628-153-90075 

00 

DFVLR4-X25 

[HDCl] 

014.000.000.017 

3110-213-00032 

00 

ISI-VAN-GW 

[JD21] 

014.000.000.018 

2624-522-80900 

52 

DFVLR5-X25 

[HDCl] 

014.000.000.019 

2041-170-10000 

00 

SHAPE-X25 

[JFW] 

014.000.000.020 

5052-737-20000 

50 

UQNET 

[AXH] 

014.000.000.021 

3020-801-00057 

50 

DMC-CRCl 

[JR17] 

014.000.000.022- 

■014.255.255.254 

Unassigned 

[JBP] 

014.255.255.255 

Reserved 

[JBP] 

The  standard  for  transmission  of  IP  datagrams  over  the  Public  Data 
Network  is  specified  in  RFC  877  [60] . 


Reynolds  &  Postel  [Page  29] 


3-203 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE  1985 


Assigned  Numbers  RFC  960 

Telnet  Options 


ASSIGNED  TELNET  OPTIONS 

The  Telnet  Protocol  has  a  number  of  options  that  may  be  negotiated. 
These  options  are  listed  here.  "Official  ARPA- Internet 
Protocols"  [104]  provides  more  detailed  information. 


Options 

Name 

References 

0 

Binary  Transmission 

[97,JBP] 

1 

Echo 

[98,JBP] 

2 

Reconnection 

[7,JBP] 

3 

Suppress  Go  Ahead 

[101, JBP] 

4 

^^rox  Message  Size  Negotiation 

[40,JBP] 

5 

Status 

[100, JBP] 

6 

Timing  Mark 

[102, JBP] 

7 

Remote  Controlled  Trans  and  Echo 

[94,JBP] 

8 

Output  Line  Width 

r5,JBP] 

9 

Output  Page  Size 

[6,  JBP] 

10 

Output  Carriage -Return  Disposition 

[27, JBP] 

^  1 

Cutout  Horizontal  Tab  Stops 

[31, JBP] 

12 

Output  Horizontal  Tab  Disposition 

[30, JBP] 

13 

Output  Formfeed  Disposition 

[28, JBP] 

14 

Output  Vertical  Tabstops 

[33, JBP] 

15 

Output  Vertical  Tab  Disposition 

[32, JBP] 

16 

Output  Linefeed  Disposition 

[29, JBP] 

17 

Extended  ASCII 

[123, JBP] 

18 

Logout 

[24,MRC] 

19 

Byte  Macro 

[34, JBP] 

20 

Data  Entry  Terminal 

[37,  JBP] 

22 

SUPDUP 

[26,25,MRC] 

22 

SUPDUP  Output 

[45,MRC] 

23 

Send  Location 

[59,EAK1] 

24 

Terminal  Type 

[114,MHS1] 

25 

End  of  Record 

[89,JBP1 

26 

TACACS  User  Identification 

[3,BA4i 

27 

Output  Marking 

[110, SXS] 

28 

Terminal  Location  Number 

[73,RN6] 

255 

Extended-Cations  -  List 

[96, JBP] 
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GOULD-6050 

GOULD-6080 

GOULD-9050 

GOULD-9080 

H-316 

H-60/68 

H-68 

H-68/80 

H~89 

HONEYWELL -DPS-6 

HONEYWELL-DPS-8/70 

HP3000 

HP3000/64 

IBM- 158 

IBM- 360/67 

IBM- 370/3033 

IBM- 3081 

IBM-3084QX 

IBM- 3101 

IBM-4331 

IBM-4341 

IBM-4361 

IBM-4381 

IBM-4956 

IBM-PC 

IBM-PC/AT 

IBM-PC/XT 

IBM-SERIES/1 

IMAGEN 

IMAGEN-8/300 

IMSAI 

INTEGRATED-SOLUTIONS 

INTEGRATED-S0LUTI0NS-68K 

INTEGRATED-SOLUTIONS-CREATOR 

INTEGRATED-SOLUTIONS-CREATOR-8 

INTEL- IPSC 

IRIS 

IRIS-1400 

IS-1 

IS-68010 

LMI 

LSI-11 
LSI -11/2 
LSI -11/23 
LSI -11/73 
M-6800 
M68000 
MASSCOMP 
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MC500 

MC68000 

MICROVAX 

MICROVAX-I 

MV/8000 

NAS3-5 

NCR-COMrEN-3690 

NOW 

ONYX-Z8000 

PDP-11 

PDP-11/3 

PDP-11/23 

PDP-11/24 

PDP-11/34 

PDP-11/40 

PDP-11/44 

PDP-11/45 

PDP-11/50 

PDP-11/70 

PDP-11/73 

PE-7/32 

PE-3205 

PERQ 

PLEXUS-P/60 

PLI 

PLURIBUS 

P^®AMID-90 

P^®AMID-90MX 

PYRAMID- 90X 

RIDGE 

RIDGE-32 

RIDGE-32C 

ROLM-1666 

Sl-MKIIA 

SMI 

SEQUENT 

SEQUENT- BALANCE - 80  0  0 

SGI -IRIS 

SIEMENS 

SILICON-GRAPHICS 

SILICON-GRAPHICS- IRIS 

SPERRY-DCP/10 

SUN 

SUN- 2 

SUN- 2/50 

SUN-2/100 

SUN-2/120 

SUN- 2/140 
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SUN- 2/150 

SUN- 2/160 

SUN- 2/170 

SUN- 3/160 

SUN- 3/75 

SUN-50 

SUN-100 

SUN-120 

SUN- 130 

SUN-150 

SUN-170 

SUN-68000 

SYMBOLICS- 3600 

SYMBOLICS-3670 

TANDEM-TXP 

TEK-6130 

TI -EXPLORER 

TP-4000 

TRS-00 

UNIVAC-1100 

UNI VAC- 1100/60 

UNIVAC-1100/62 

UNIVAC-1100/63 

UNIVAC-1100/64 

UNIVAC-1100/70 

UNI VAC- 1160 

VAX- 11/725 

VAX- 11/730 

VAX- 11/750 

VAX- 11/780 

VAX- 11/785 

VAX-11/790 

VAX -11/8600 

VAX -0600 

WANC-PC002 

WANC-VSIOO 

WANG-VS400 

XEROX-1100 

XEROX-1108 

XEROX-8010 


RFC  960 
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System  Names 


OFFICIAL  SYSTEM  NAMES 

These  are  the  Official  System  Names  as  they  appear  in  the  NIC  Host 
Table.  Their  use  is  described  in  RFC  810  [41]  . 

AEGIS 

APOLLO 

BS-2000 

CEDAR 

CGW 

CHRYSALIS 

CMOS 

CMS 

COS 

CPIX 

CTOS 

DCN 

DDNOS 

DOMAIN 

EDX 

ELF 

EMBOS 

EMMOS 

EPOS 

FOONEX 

FUZZ 

GCOS 

GPOS 

HDOS 

IMAGEN 

INTERCOM 

IMPRESS 

INTERLISP 

lOS 

ITS 

LISP 

LISPM 

LOCUS 

MINOS 

MOS 

MPE5 

MSDOS 

MULTICS 

MVS 

MVS/SP 

NEXUS 

NMS 

NONSTOP 
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NOS- 2 

OS/DDP 

0S4 

0S86 

OSX 

PCDOS 

PERQ-OS 

PLI 

PSDOS/'MIT 

RMX,/RDOS 

ROS 

RSXllM 

SATOPS 

SCS 

SIMP 

SWIFT 

TAG 

TANDEM 

TENEX 

TOPS-10 

TOPS- 20 

■IP3010 

TRSDOS 

ULTRIX 

UNIX 

UT2D 

V 

VM 

VM/370 

VM/CMS 

VM/SP 

VMS 

VMS/EUNICE 

VRTX 

WAITS 

WANS 

XDE 

XENIX 
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MPM 

MPM-FLAGS 

MSG-AUTH 

MSG-ICP 

MUX 

NAMESERVER 

NETED 

NETRJS 

NI-FTP 

NI-MAIL 

NICNAME 

NSW-FE 

NTP 

NVP-II 

POP2 

PRM 

PUP 

QUOTE 

PDP 

RJE 

RLP 

RTELNET 

RVD 

SAT-EXPAK 

SAT-MON 

SFTP 

SMIP 

ST 

SU-MIT-TG 

SUNRPC 

SUPDUP 

SUR-MEAS 

SWIFT-RVF 

TACACS-DS 

TACNEWS 

TCP 

TELNET 

TFTP 

TIME 

TRUNK- 1 

TRUNK- 2 

UCL 

UDP 

UNTP 

USEP^ 

UUCP-PATH 

VIA-FTP 

WB-EXPAK 
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Internet  Message  Protocol  (Multimedia  Mail) 

MP  Flags  Protocol 

MSG  Authentication  Protocol 

MSG  I CP  Protocol 

Multiplexing  Protocol 

Host  Name  Server 

Network  Standard  Text  Editor 

Remote  Job  Service 

NI  File  Transfer  Protocol 

NI  Mail  Protocol 

Who  Is  Protocol 

NSW  User  System  Front  End 

Network  Time  Protocol 

Network  Voice  Protocol 

Post  Office  Protocol  -  Version  2 

Packet  Radio  Measurement 

PUP  Protocol 

Quote  of  the  Day  Protocol 
Reliable  Data  Protocol 
Remote  Job  Entry 
Resource  Location  Protocol 
Remote  Telnet  Service 
Remote  Virtual  Disk  Protocol 
Satnet  and  Backroom  EXPAK 
SATNET  Monitoring 
Sii^le  File  Transfer  Protocol 
Sinple  Mail  Transfer  Protocol 
Stream  Protocol 

SU/MIT  Telnet  Gateway  Protocol 

SUN  Remote  Procedure  Call 

SUPDUP  Protocol 

Survey  Measurement 

Remote  Virtual  File  Protocol 

TACACS -Database  Service 

TAG  News 

Transmission  Control  Protocol 
Telnet  Protocol 

Trivial  File  Transfer  Protocol 
Time  Server  Protocol 
Trunk- 1  Protocol 
Trunk- 2  Protocol 

University  College  London  Protocol 

User  Datagram  Protocol 

USENET  News  Transfer  Protocol 

Active  Users  Protocol 

UUCP  Path  Service 

VIA  Systems-File  Transfer  Protocol 

Wideband  EXPAK 
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RFC  960 


WB-MON 

XNET 

XNS-IDP 


-  Wideband  Monitoring 

-  Cross  Net  D^ugger 

-  Xerox  NS  IDP 
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OFFICIAL  TERMINAL  TYPE  NAMES 

Tbese  are  the  Official  Terminal  Type  Names.  Their  use  is  described 
in  RFC  930  [114]  .  The  maximum  length  of  a  name  is  40  characters. 

ADDS-CONSUL-980 

ADDS -REGENT- 100 

ADDS-REGENT-20 

ADDS -REGENT- 200 

ADDS-REGENT-25 

ADDS -REGENT- 40 

ADDS-REGENT-60 

AMPEX-DIALOGUE-80 

ANDERSON- JACOBSON- 6  30 

ANDERSON- JACOBSON-832 

ANDERSON- JACOBSON-841 

ANN-ARBOR-AMBASSADOR 

ARDS 

BITGRAPH 

BUSSIPLEXER 

CALCOMP-565 

CDC-456 

CDI-1030 

CDI-1203 

CLNZ 

COMPUCOLOR-II 
CONCEPT-100 
CONCEPT- 104 
CONCEPT- 103 
DATA-100 

DATA-GENERAL-6053 

DATAGRAPHIX-132A 

DATAMEDIA-1520 

DATAMEDIA-1521 

DATAMEDIA-2500 

DATAMEDIA-3025 

DATAMEDIA-3025A 

DATAMEDIA-3045 

DATAMEDIA-3045A 

DATAMEDIA-DT80/1 

DATAPOINT-2200 

DATAPOINT-3000 

DATAPOINT-3300 

DATAPOINT-3360 

DEC-DECWRITER-I 

DEC-DECWRITER-II 

DEC-GT40 

DEC-GT40A 
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DEC;"Grr42 

DEC-LA120 

DEC-LA30 

DEC-LA36 

DEC-LA38 

DEC“VT05 

DEC-Vl’lOO 

DEC-VT132 

DEC-VT50 

DEC-VT50H 

DEC-VT52 

DELTA-DATA-5000 

DELTA-TELTERM-2 

DIABLO-1620 

DIABLO- 1640 

DIGILOG-333 

DTC-300S 

EDT-1200 

EXECUPORT-4000 

EXECUPORT-4080 

GENERAL-TERMINAL-IOOA 

GSI 

HAZELTINE-1500 

HAZELTINE-1510 

HAZELTINE-1520 

HAZELTINE-2000 

HP-2621 

HP-2621A 

HP-2621P 

HP-2626 

HP-2626A 

HP-2626P 

HP-2640 

HP-2640A 

HP-2640B 

HP- 2645 

HP-2645A 

HP- 2648 

HP-2648A 

HP- 2649 

HP-2649A 

IBM- 3101 

IBM-3101-10 

IBM-3275-2 
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[BSW] 

Barbara  Seber -Wagner  MITRE 

bnsw@MITRE-BEDFORD .  ARPA 

[BXA] 

Bobby  W.  Allen 

YPG 

WYMER@OFFICE . ARPA 

[BXD] 

Brian  Down 

TORONTO  bdown5OTR0NT0@CSNET-RELAY .  ARPA 

TBXG] 

Barry  Lustig 

UCLA 

BARRY@LOCUS .  UCLA .  EDU 

[BXL] 

Barry  Greenberg 

LOCUS 

— none — 

[BXM] 

Bill  Mitchell 

U  OF  ARIZ 

— none — 

»  WAA\.  j 

Chrii-  Kent 

PURDUE 

CAK@PURDUE.EDU 

[CAS] 

Carl  Sunshine 

SDC 

Sunshine@USC-ISIB . ARPA 

[CBD] 

Clive  B.  Dawson 

MCC 

Clive@MCC.ARPA 

[CBP] 

Brian  Pinkerton 

WISCONSON 

Erian@WISC-RSai.ARPA 

[CJC3] 

Chase  Cotton 

UDEL 

Cotton@UDEL- EE . ARPA 

[CH2] 

Charles  Homig 

SYMBOLICS 

CAH@MIT-MC.ARPA 

[CJW2] 

Cliff  Weinstein 

LL 

cJw@LL-SST.ARPA 

[CLH3] 

Charles  Hedrick 

RUTGERS 

Hedrick@RUTGERS .  EDU 

[CMR] 

Craig  Rogers 

ISI 

Roger s@UbC - I S I B . ARPA 

[CPIO] 

Craig  Partridge 

BBN 

craig@BBN-UNIX .ARPA 

[CXH] 

Chien  Y.  Huang 

PRINCETON 

6026959%PUCC .  BINET@WISCVM.  ARPA 

[CXL] 

Clifford  A.  Lynch 

BERKELEY 

udcia%ueb topaz  .  cc(s)UCBARPA .  BERKELEY ,  EDU 

PAMI] 

David  A .  Mosher 

BERKELEY 

Mosher@UCBARPA . BERKELEY . EDU 
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[DAVE]  David  Roode 

[DBJ]  David  B.  Johnson 

[DCPl]  David  Plummer 

[DDCl]  David  Clark 

[DTI 5]  Dan  Tappan 

[DG28]  David  L.  Gehrt 

[DH17]  Douglas  Hirsch 

[DHH]  Doug  Hunt 

[DJF]  David  J.  Farber 

[DJVl]  Darrel  J.  Van  Buer 

[DK2]  Dean  B.  Krafft 

[DLMl]  David  Mills 

[DPR]  David  Reed 

[DRP]  Don  Provan 

[DRS4]  Dennis  R.  Smith 

[DSW]  Dan  Whelan 

[DVC]  Don  Cone 

[DXB]  David  Bloom 

[DXD]  Dennis  J.W.  Dube 

[DXG]  David  Goldberg 

[DXS]  Don  Scelza 

[DXT]  Dave  Taylor 

[EAKl]  Earl  Killian 

[EBM]  Eliot  Moss 

[EC5]  Ed  Cain 

[EF5]  Ed  Franceschini 

[EHP]  Ed  Perry 

[EXY]  Elaine  Yamin 

[FAS]  Fred  Segovich 

[FLM2]  F.  Lee  Maybaum 

[FRAN]  Francine  Peril lo 

[FXS]  Frank  Solensky 

[GEOF]  Geoff  Goodfellow 

[GAA]  Glenn  A.  Adams,  Jr. 

[GC]  Graham  Canpbell 

[GH29]  Gregory  Hidley 

[GIH]  Glenn  I.  Hastie  II 

[GLH5]  Gavin  L.  Hamphlll 

[GPIO]  George  Pavel 

[GW22]  Grant  Weller 

[GXL]  Guillermo  A.  Loyola 

[GXP]  Gill  Pratt 

fHCF2]  Harry  Forsdlck 

[HDCl]  Horst  Clausen 

[HDW2]  Howard  Wactlar 

[HGM]  Ha 11 am  Murray 

[HM]  Hank  Magnuski 

[HWB]  Hans -Werner  Braun 


Intel liCorp  Roode@SUMEX-AIM. ARPA 

DRILLTECH  DBJ@RICE.ARPA 

MIT  DCP@SYMBOL I CS . ARPA 

MIT  DClark@BBN-UNIX . ARPA 

BBN  Tappan@BBNG .  ARPA 

RIACS  Dave@RI  ACS.  ARPA 

BBN  hir sch@BBNCCS . ARPA 

BBN  DHunt@BBNCCJ.ARPA 

UDEL  Farber@UDEL -EE . ARPA 

SDC  vanbuer@USC - ECL . ARPA 

CORNELL  Dean@CORNELL . ARPA 

LINKABIT  Mills@USC-ISID.ARPA 

MIT-LCS  Reed@MIT-MULTICS.ARPA 

LLNL  Provan@LLL-MFE . ARPA 

use  Smith@USC-ECLC . ARPA 

CALTECH  Dan@CIT-20.ARPA 

SRI  C0NE@SRI -SPAM. ARPA 

RUTGERS  andr omeda ! b 1 oom@RUTGERS . EDU 

VIA  SYSTEMS  ---none--- 

SMI  sun !  dg@UCBARPA .  BERKELEY .  EDU 

PERQ  - none - 

INFERENCE - none--- 

LLL  EAK@S1-C.ARPA 


MIT 

DCEC 

NYU 

SRI 

ATT 

GSWD 

MILNET 

SRI 

PRIME 

SRI 

mital 

BNL 

UCSD 

SRI 

DREA 

LLNL 

UTAH 

IBM 

MIT 

BBN 

DFVLR 

CMU 

XEROX 

MICHIGAN 


sun !  dg@UCBARPA .  BERKELEY .  EDU 

- none - 

— none--- 
EAK@S1-C.ARPA 
EBM@MIT-XX.ARPA 
cain@EDN-UNIX . ARPA 
Franceschini@NYU . ARPA 
Perry@SRI-KL.ARPA 
— none — 
fred@GSWD-VMS .ARPA 
Maybaum@DDNl  .ARPA. 

Per illo@SRI -NIC .ARPA 

- none - 

Geo  f  f@SRI -CSL . ARPA 
glGnn@LL-XN.ARPA 
gc@BNL.AJRP  A 
hidley@UCSD.ARPA 
Has t ie@SR I - SPAM . ARPA 
Hemphl 1 1@DREA- XX . ARPA 
liaison@LLL-TIS.ARPA 
Weiler@UTAH-20 .ARPA 
Loy o 1 a% ibm - s  j  @CSNET - R  ELAY . ARPA 
gi 1 1 %mi t - ccc@MI T- MC . ARPA 
For sdick@BBNA . ARPA 
C 1  ausen@USC  - 1 S I D .  ARi’A 
Wac t 1 a r @CMU - CS - A . ARP A 
Murray . PA@XER0X . ARPA 
J0SE@XER0X.PA.ARPA 
HWB@'UMICH1  .ARPA 
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[JAl] 

Jules  P.  Aronson 

NLM 

Aronson@NLM-MCS .ARPA 

[JAG3] 

Jeff  Gumpf 

CWRU 

G.Guiipf@COLUMBIA-20  .ARPA 

[JAKE] 

Jake  Felnler 

SRI 

Felnler(siSRI  -NIC  .ARPA 

[JAR4] 

Jim  Rees 

WASHINGTON  JINKaWASHINGTON.ARPA 

[JBP] 

Jon  Postel 

ISI 

Postel@USC - I S I B . ARPA 

[JBWl] 

Joseph  Walters,  Jr. 

BBN 

JWalters@BBNCCX . ARPA 

[JCll] 

Jim  Clifford 

LAND 

Jrc@LANL.ARPA 

[JCN2] 

John  C.  Nunn 

NBS 

NUNN@NBS -VMS . ARPA 

[JD21] 

Jonathan  Dreyer 

BBN 

JDr  eyerdiBBNCCV .  ARPA 

[JDG] 

Jim  Guyton 

RAND 

guyton@RAND-UNIX .  ARPA 

[JEM] 

Jim  Mathis 

SRI 

Mathis@SRI  -KL .  ARPA 

[JFH2] 

Jack  Haver ty 

BBN 

Haver  ty@BBNCCV .  ARPA 

[JFW] 

Jon  F.  Wilkes 

STC 

Wllkes@STC.ARPA 

[JGH] 

Jim  Herman 

BBN 

Herman@BBNCCJ  .ARPA 

[JG46] 

Jonathan  Goodman 

YALE 

Goodman@YALE  .ARPA 

[JKRl] 

Joyce  K.  Reynolds 

ISI 

JKREYNOLDS@USC - I SI B . ARPA 

[JL15] 

Jay  Lepreau 

UTAH 

Lepreau@UTAH-CS .  ARPA 

[JLM23] 

John  L.  Mills 

HONEYWELL 

Mllls:§CISL-SERVICE-MULTICS  .ARPA 

[JOS] 

John  O'Donnell 

YALE 

ODonnel 1@YALE . ARPA 

[JR15] 

John  Rhodes 

LOGNET 

JRhodes@LOGNET2  .ARPA 

[JR17] 

John  L.  Robinson 

CANADA 

Roblnson@DMC-CRC  .ARPA 

[JRMl] 

John  Mullen 

MITRE 

Mullen(§MITRE .  ARPA 

[JRS8] 

Jeffrey  R.  Schwab 

PURDUE 

irs@PlTRDUE.EDU 

[JS38] 

Josqph  Sventek 

LBL 

JSSventek@LBL .ARPA 

[JSG5] 

Jon  Goodrldge 

BBN 

Jsg(slBBNCCM.ARPA 

[JSQl] 

John  S.  Quarterman 

UT 

JrcfiUT-SALLY.ARPA 

[JWl] 

Jill  Westcott 

BBN 

Westco  ct@BBNA . ARPA 

[JWF] 

Jim  Forgle 

James  W.  O’Toole 

LL 

JVfi'@LL-EN.ARPA 

[JWOl] 

UMD 

J  ames@MARYL.AND .  ARPA 

[JXB] 

John  Blair 

NEOCM 

cbosgd !  neoucom !  J  ohnb@UCBARPA .  BERKELEY .  EDU 

[JXD] 

Jean  Darling 

WISC-MADI 

Dar 1 ing@UWI SC . ARPA 

[JXJ] 

Jackie  Jones 

NBS 

- none - 

[JXO] 

Jack  O'Neil 

ENCORE 

- none - 

[JXS] 

J.  Slmonetti 

SUNY 

Joes@SBCS . ARPA 

[JXY] 

Joe  Yancone 

USARMY 

Yancone@CRDC .  ARPA 

[KCSl] 

Kevin  C.  Smallwood 

PURDUE 

kcs@PURDUE.EDU 

rKFDI 

Ken  Dove 

AIDS 

kfd@AID-UNIX.ARPA 

[KLH] 

Ken  Harrenstien 

SRI 

KLH@^SRI -NIC.  ARPA 

[KMC3] 

Kenneth  M.  Crepe? 

SRI 

Crepea@SRI  -SPAM  .ARPA 

[KOll] 

Kevin  O'Keefe 

HAZELTINE  Hazeltine@USC-ISI . ARPA 

[KRS] 

Karen  So 11 ins 

MIT 

So  1 1  lns@MIT- XX .  ARPA 

[KTP] 

Kenneth  T,  Pogran 

BBN 

Pogr an@BBNBBNCCQ . ARPA 

[KWP] 

Kevin  W.  Paetzold 

DEC 

Paetzold@DEC-MARLBORO .ARPA 

[KXC] 

Ken  Chen 

Perceptronics  - none - 

[KXS] 

Kathy  Slnpson 

OSU 

- none - 

[LB3] 

Lun  Bo sack 

STANFORD 

Bosack@SU-SCORE . ARPA 

Reynolds  & 
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CLB16] 

Lludvlkas  Bukys 

ROCHESTER  Bukys^OCHESTER.ARPA 

[LCN] 

Lou  Nelson 

AEROSPACE  Lou@AEROSPACE.ARPA 

[LCS] 

Lou  Schreler 

SRI 

Schreler@USC-ISID  .ARPA 

[LH2] 

Lincoln  Hu 

COLUMBIA 

Hu@COLUMBIA-20  .ARPA 

[LOU] 

Lou  Salklnd 

NYU 

Salklnd@NYU.ARPA 

[LMS] 

Liza  Mai  Lin 

MIT-LCS 

Martln@MIT-XX .  ARPA 

[LRB] 

Larry  Blerma 

NPRDC 

Blenna@NPRDC .  ARPA 

[LWR] 

Larry  Robinson 

LLNL 

lwr@Sl-C.ARPA 

[LXL] 

Len  Lattanzl 

SENTRY 

- none - 

[MA] 

Mike  Accetta 

CMU 

MI  KE .  ACCETTA@CMU-CS  -  A .  ARPA 

[MAM] 

Mark  Brown 

use 

Mark@USC-ECLB . ARPA 

[MAE] 

Marc  A.  Elvy 

HARVARD 

elvy@HARVARD.EDU 

[MBG] 

Michael  Greenwald 

MIT-LCS 

Greenwald@MIT-MULTICS  .ARPA 

[MB] 

Michael  Brescia 

BBN 

Brescla@BBNCCV . ARPA 

[MB31] 

Michael  BereschlnskyUSARMY 

Bereschlnsky@USC-ISID  .ARPA 

[MCAl] 

Mary  C.  Akers 

FISG 

MCAkers@frPSG-T .  ARPA 

[MCSJ] 

Mike  St  Johns 

TPSC 

StJohns@MIT-MULTICS  .ARPA 

[MDC] 

Martin  D.  Connor 

MIT  AI 

Marty@MIT-HrVAX .  ARPA 

p1F31] 

Martin  J.  Fouts 

NASA-AMES 

f  outs@AMES  -NAS .  ARPA 

[MH12] 

Mark  Horton 

ATT 

mark@UCBARPA .  BERKELEY .  EDU 

[HJM2] 

Mike  Muuss 

BRL 

Mlke@BRL.ARPA 

[MK17] 

Mike  Karels 

BERKELEY 

Karols@UCBARPA .  BERKELEY .  EDU 

[MKLl] 

Mark  Lottor 

MIT 

MKL@SRI -NIC.  ARPA 

[MLC] 

Mike  Corrigan 

DDN 

Corrlaan@DDNl  .ARPA 

[M02] 

Michael  O'Brien 

RAND 

OBrleriSRAND-UNIX  .ARPA 

[M014] 

Michele  Olivant 

JHJ 

011vant@HAWAI  I  -EMH .  ARPA 

[MRC] 

Mark  Crispin 

STANFORD 

Admin .  MRC@SU  -  SCORE .  ARPA 

[MS9] 

Martin  Schoff stall 

RPI 

schof  f%rpl@CSNET-RELAY .  ARPA 

[MS56] 

Marvin  Solomon 

Wise 

Solomon@UWISC . ARPA 

[MSMl] 

Milo  S.  Medln 

AMES 

medln@AMES  .ARPA 

[MIR] 

Marshall  Rose 

IRVINE 

MRose . UCI@RAND-RELAY . ARPA 

[MXA] 

Melanie  Anderson 

UIUC  Melanle%UIUCVMD.BITNET@WISCVM.ARPA 

[MXAl] 

M.  Aziza 

INRIA 

- none - 

[MXG] 

Mike  Gilbert 

SLI  Software -Lever  ag^iUSC-ECLB.ARPA 

[MXH] 

Martin  Hayman 

Symbolics 

- none - 

[MXK] 

Michael  K^ar 

CMU 

Mike .  Kaz  ar@CMU-CS  -K .  ARPA 

[MXM] 

Marc  M.  Melllevir 

COINS 

COINS@USC-ISI .ARPA 

[MXP] 

Michael  K.  Peterson 

HUGHES 

scgvaxd !  mkp@CIT- VAX .  ARPA 

[MXPl] 

Mark  C.  Powers 

NSWC 

iipowers@NSWC  -G .  ARPA 

[MXR] 

Mark  A.  Rcsensteln 

MIT 

mar(g^^IT*•  BORAX  .ARPA 

[MXS] 

Marc  Shapiro 

INRIA 

Marc .  Shaplro@C  .CS.CMU.EDU 

[NC3] 

J.  Noel  Chlappa 

MIT 

JNC@MIT-XX.ARPA 

[NG] 

Nell  Gower 

ROCKWELL 

GOWER@USC- ISID .  ARPA 

P^] 

Mike  Mlnnlch 

UDELEE 

NMlnnlch@UDEL  -HUEY .  ARPA 

fNXH] 

Nat  Howard 

IM 

nrh@ODNl .ARPA 

[NXK] 

Nell  Katin 

HP 

hpda .  nol  1@UCBARPA .  BERKELEY .  EDU 

[PAS] 

Philip  Almqulst 

STANFORD 

Almqulst@SU-SCORE  .ARPA 

[PAM6] 

Paul  McNabb 

RICE 

pam@PURDUE.EDU 

Reynolds  4e  Postel 
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[PFS2]  Paul  Sass  CECOM  Sass@USC-ISID.AKPA 

[PGM]  Paul  G.  Milazzo  RICE  Milazzo@RICE.ARPA 

[PHDl]  Pieter  Ditmars  BBN  pditmars@BBNCCX.ARPA 

[PK]  Peter  Kirstein  UCL  Kirstein@USC-ISI  .ARPA 

rPK28]  Philip  R.  Kam,  Jr.  BCR  Kam@BELLCORE-CS-GW.ARPA 

[PL4]  Phil  Lapsley  BERKELEY  phil@UCBARPA.BERKELEY.EDU 

[PMl]  Paul  Mockapetris  ISI  Mockapetrls@USC-ISIB.ARPA 

[PM4]  Paul  Martin  SRI  PMartin@SRI-AI  .ARPA 

[P327]  Paal  Spilling  NTA  Spllling@USC-ISID.ARPA 

[PXA]  Phillip  G.  Apley  BITSTREAM  PGA@MIT-OZ.ARPA 

[PXB]  Pat  Boy}e  UBC  boy le.ubc@CSNET-RELAY. ARPA 

[PXD]  Pete  Delaney  ECRC  pete%ecrcvax@CSNET-RELAY.ARPA 

[PXM]  Pat  Marcjues  NSRDC  marques@DTRC.ARPA 

[PXN]  Peter  Nellessen  SIEMENS  crtvax!pn@CMU-CS- SPICE. ARPA 

[RAll]  Rick  Adams  CCI  Rick@SEISMO.CSS.GOV 

[RA17]  Bob  Albrlghtson  WASHINGTON  BOB@WASHINGTON.ARPA 
[RB9]  Richard  Bisbey  ISI  Bisbey@USC-ISIB.ARPA 

[P.BN1]  Ronald  Natalie,  Jr.  BRL  ron@BRL-TGR.ARPA 

[RBW]  Richard  B.  Wales  UCLA  WALES@LOCUS.UCLA.EDU 

[RHC3]  Robert  Cole  UCL  robert@UCL-CS.ARPA 

[RC77]  Robert  Carey  YALE  CAREY@YALE.ARPA 

[RDB2]  Robert  Bressler  BBN  Bressler@BBNCCW.ARPA 

[RDR41  Dennis  Rockwell  BBN  DRockwell@CSNET-SH.ARPA 

[RFDl]  Robert  F.  Donnelly  ARDC  donnelly@ARDC.ARPA 

CRG12]  Roger  L.  Gulbranson  UMINN  ROGERG@UMN-UCC-VA.ARPA 

[RH6]  Robert  Hlnden  BBN  Hlnden@BBN-CCV.ARPA 

[RH60]  Roger  Hale  MIT  Roger@LL-SST.ARPA 

[RHC3]  Robert  Cole  UCL  Robert@USC-CS.ARPA 

[RHT]  Robert  Thomas  BBN  BThomas@BBNF.ARPA 

[R1CJ2]  Richard  Johnsson  DEC  JohnssortgDECWRL.ARPA 

[RL2]  Randy  C.  Lee  HONEYWELL  RCLee@HI -MULTI CS. ARPA 

[RLB3]  Ronald  L.  Broersma  NOSC  Ron@NOSC.ARPA 

CRLH2]  Ronald  L.  Hartung  NSWC  ron@NSWC-WO.ARPA 

[RLS6]  Ronald  L.  Smith  COINS  COINS@USC- ISI .ARPA 

[RMS]  Roy  Marantz  RUTGERS  Marantz@RUTGERS.EDU 

[RN6]  Rudy  Nedved  CMU  Rudy .Nedved@CMU-CS-A.ARPA 

[RNMl]  Nell  MacKenzie  RSRE  CLE%RSRE@UCL-CS.ARPA 

[RR2]  Raleigh  Romlne  TELEDYNE  romine@SEISMO.CSS.GOV 

[RR18]  Ron  Relsor  UDEL  ron@UDEL-EE.ARPA 

[RR26]  William  R.  Reilly  USARMY  RREILLY@JPL-MILVAX.ARPA 

[RS23]  Russel  Sandberg  WISC  root@UWISC.ARPA 

[RSMl]  Robert  S.  Miles  ^^RTC  RSM@BRL.ARPA 

[RTB3]  Bob  Braden  UCLA  Braden@UCLA-CCN. ARPA 

[PWS4]  Robert  W.  Scheifler  ARGUS  RWS@MIT-XX.ARPA 

[RXB]  Rafael  Bracho  SPAR  RXB@SRI-KL.ARPA 

[RXBl]  Randolph  Bentson  CSU 

Bentson%Co  1  oState@CSNET-RELAY .  ARPA 
[RXG]  Richard  Gopstein  RCA  Gopstein@RUTGERS.EDU 
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[RXJ] 

Ronald  Johnson 

APPLE 

r  1  j%appie@CSNET-RELAY .  ARPA 

[RXM] 

Robert  Myhill 

BBN 

Myhi 1 1@BBNCCS . ARPA 

[SAl] 

Sten  Andler 

ARPA 

andler .  ibm-s  j@ElAND-RELAY .  ARPA 

[SA2] 

Saul  Amarel 

ARPA 

AmarGl@USC-ISI  .ARPA 

rsc3i 

Steve  Casner 

ISI 

Casner@USC  - 1 S I B .  ARPA 

[SGC] 

Steve  Chlpman 

BBN 

Chipman@BBNF .  ARPA 

[SHB] 

Steven  Blumenthal 

BBN 

BLUMENTHAL@BBN- VAX .  ARPA 

rsK8] 

Steve  Kille 

ua. 

Steve@UCL -CS . ARPA 

[SM6] 

Sean  McLinden 

DSL 

McLindenORUTGERS ,  EDU 

[SMFJ 

Steven  M.  Feldman 

TYMNET 

ARPAVAX .  f eldman@UCEARPA .  BERKELEY .  EDU 

[SXA] 

Skip  Addison 

GATECH 

Skip !  gatech .  csnet@CSNET -RELAY .  ARPA 

[SXB] 

Steve  Byrne 

TARTAN 

Byme@CMU-CS-C  .ARPA 

[SB28] 

Scott  Bradner 

HARVARD 

sob@HARVARD.EDU 

[SXF] 

Steve  Fogel 

MTCS 

SFoge  1 !  mtes !  mtxinu@uCBARPA .  BERKELEY .  EDU 

[SXM] 

Scott  Marcus 

SPARTACUS 

— none — 

[SXMl] 

Scooter  Morris 

GENENTECH  scooter<§lUCSF-CGL  .ARPA 

[SXS] 

Steve  Silverman 

MITRE 

Blankert@MITR-E-GATEWAY .  ARPA 

[TBS] 

Claude  S.  Stef fey 

WSMR 

cstef fey@WSMRCASl . ARPA 

CTC4] 

Tony  Cincotta 

DTNSRDC 

tony@NALCON.ARPA 

[ire] 

Thomas  Ferrin 

UCSF 

Ferrin@UCSF-CGL .  ARPA 

[THD] 

Thomas  Dunigan 

ORNL 

dunigan@ORNL-MSR .  ARPA 

[TML] 

T.  Michael  Louden 

MITRE 

LoudengMITRE-GW.ARPA 

[TWll] 

Tom  Wadlow 

LLL 

TAW@S1-C.ARPA 

[TXB] 

Ted  Baker 

FSU 

baker@WASHINGTON .  ARPA 

[TXM] 

Trudy  Miller 

ACC 

Trudy@ACC.ARPA 

[TJCN] 

Todd  Nugent 

U  CHICAGO  Nugent@ANL-MCS.ARPA 

[UXB] 

Ulf  Bilting 

CHALMERS 

bilting@PURDOE.EDU 

[WDL] 

Walter  Lazear 

MITRE 

Lazear@MITRE.ARPA 

[WC] 

Wayne  Graves 

LBL 

WLGraves@LBL.ARPA 

[WF3] 

William  E.  Fink 

NRLRCD 

bill@NRL.ARPA 

[WIM] 

William  Maegregor 

BBN 

macg@BBN.ARPA 

[WJC2] 

Bill  Croft 

STANFORD 

Cr  o  f  t@SUMEX-AIM .  ARPA 

[WPJ] 

William  Jones 

USRA 

Jones@AMES-VMSB .  ARPA 

[WW2] 

Wally  Wedel 

NBI 

wedel@UT-NGP .  ARPA 

[WWS] 

Bill  Seemuller 

USARMY 

bill@ETL.ARPA 

[WXL] 

William  Lampeter 

UR 

bi 1 1@R0CHESTER . ARPA 

[ZSU] 

Zaw'Sing  Su 

SRI 

ZSu@SRI-TSC.ARPA 
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Network  Numbers 

The  network  numbers  in  class  A,  B,  and  C  network  addresses  are 
allocated  among  Research,  Defense,  Government  (Non-Defense)  and 
Commercial  uses. 

Class  A  (highest- order  bit  0) 


Research  allocation:  8 

Defense  allocation:  24 

Government  allocation:  24 

Commercial  allocation:  94 

Reserved  Addresses:  (0,  127) 

Total  128 

Class  B  (highest -order  bits  1-0) 

Research  allocation:  1024 

Defense  allocation:  3072 

Government  allocation:  3072 

Commercial  allocation:  12286 

Reserved  Addresses:  (0,  16383) 

Total  16384 

Class  C  (highest -order  bits  1-1-0) 

Research  allocation:  65536 

Defense  allocation:  458725 

Government  allocation:  458725 

Commercial  allocation:  1572862 

Reserved  Addresses:  (0,  2097151) 
Total  2097152 

Class  D  (highest -order  bits  1-1-1) 


All  addresses  in  this  class  are  reserved  for  future  use. 

Within  the  Research  community,  network  identifiers  will  only  be 
granted  to  ap)pllcants  who  show  evidence  that  they  are  acquiring 
standard  Bolt  Beranek  and  Newman  gateway  software  or  have 
implemented  or  are  acquiring  a  gateway  meeting  the  Exterior 
Gateway  Protocol  requirements.  Acquisition  of  the  Berkeley  BSD 
4.2  UNIX  software  might  be  considered  evidence  of  the  latter. 
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E^qjerimental  networks  which  later  become  operational  need  not  be 
renumbered.  Rather,  the  identifiers  could  be  moved  from  Research 
to  Defense,  Government  or  Commercial  status.  Ihus,  network 
identifiers  may  change  state  among  Research,  Defense,  Government 
and  Commercial,  but  the  number  of  identifiers  allocated  to  each 
use  must  remain  within  the  limits  indicated  above.  To  make 
possible  this  fluid  assignment,  the  network  identifier  spaces  are 
not  allocated  by  simple  partition,  but  rather  by  specific 
assignment . 

Protocol  Identifiers 

These  assignments  are  shared  by  the  four  communities. 

Port  Numbers 

These  assignments  are  shared  by  the  four  communities. 

ARPANET  Link  Numbers 

These  assignments  are  shared  by  the  four  communities. 

IP  Version  Numbers 

These  assignments  are  shared  by  the  four  communities. 

TCP,  IP  and  Telnet  Option  Identifiers 

These  assignments  are  shared  by  the  four  communities. 
Inplementation : 

Joyce  Reynolds  is  the  coordinator  for  all  number  assignments. 
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PRE-EMPTION 

In  circuit -switching  systems,  once  a  user  has  acquired  a  circuit,  the 
communication  bandwidth  of  that  circuit  is  dedicated,  even  if  it  is  not 
used.  When  the  system  saturates,  additional  circuit  set-up  requests  are 
blocked.  To  allow  hig^  precedence  users  to  gain  access  to  circuit 
resources,  systems  such  as  AUTOVON  associate  a  precedence  with  each 
telephone  instrument.  Those  instruments  with  high  precedence  can 
pre-empt  circuit  resources,  causing  lower  precedence  users  to  be  cut 
off. 

In  message  switching  systems  such  as  AUTODIN  I,  incoming  traffic  is 
stored  on  disks  (or  drums  or  tape)  and  processed  in  order  of 
precedence.  If  a  hi precedence  message  is  entered  into  the  system,  it 
is  processed  and  forwarded  as  quickly  as  possible.  When  the  high 
precedence  message  arrives  at  the  destination  message  switch,  it  may 
pre-empt  the  use  of  the  output  devices  on  the  switch,  interrupting  the 
printing  of  a  lower  precedence  message. 

In  packet  switching  systems,  there  is  little  or  no  storage  in  the 
transport  system  so  that  precedence  has  little  impact  on  delay  for 
processing  a  packet.  However,  when  a  packet  switching  system  reaches 
saturation,  it  rejects  offered  traffic.  Precedence  can  be  used  in 
saturated  packet  switched  systems  to  sort  traffic  queued  for  entry  into 
the  system. 

In  general,  precedence  is  a  tool  for  deciding  how  to  allocate  resources 
when  systems  are  saturated.  In  circuit  switched  systems,  the  resource 
is  circuits;  in  message  switched  systems  the  resource  is  the  message 
switch  processor;  and  in  packet  fiwitching  the  resource  is  the  packet 
switching  system  itself. 

This  capability  can  be  realized  in  AUTODIN  II  without  adding  any  new 
mechanisms  to  TCP  (except  to  ma].<e  precedence  of  incoming  connection 
requests  visible  to  the  processes  which  use  TCP) .  To  allow  pre-emptive 
access  to  a  particular  terminal,  the  software  (i.e.,  THP)  which  supports 
terminal  access  to  the  TAC  can  he  configured  so  as  to  always  have  a 
LISTEN  posted  for  that  terminal,  even  if  the  terminal  has  a  connection 
in  operation.  For  exanple  in  the  ARPAl'IET  TENEX  systems,  the  user  TELNET 
permits  a  user  to  have  mciny  connections  open  at  one  time  -  the  user  can 
switch  among  them  at  will.  To  the  extent  that  this  can  be  done  without 
violating  security  requirements,  one  could  imagine  a  multi -connection 
THP  which  always  leaves  a  LISTEN  pending  for  incoming  connection 
requests.  If  a  connection  is  established,  the  THP  can  decide,  based  on 
its  precedence,  whether  to  pre-empt  any  existing  connection  and  to 
switch  the  user  to  the  high  precedence  one. 

If  the  user  is  working  with  several  connectlon.s  of  different  precedence 
at  the  same  time,  the  THP  would  close  or  abort  the  lowest  precedence 
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connection  in  favor  of  the  higher  precedence  pre-empting  o.ie.  Then  the 
THP  would  do  a  new  LISTEN  on  that  terminal's  port  in  case  a  hig^i3r 
precedence  connection  is  attenpted. 

One  of  the  reasons  for  suggesting  this  model  is  that  processes  are  the 
users  of  TCP  (in  general)  and  that  TCP  itself  cannot  cause  processes  to 
be  created  on  behalf  of  an  incoming  connection  request.  Inplementations 
could  be  realized  in  which  TCPs  accept  incoming  connection  requests  and, 
based  on  the  destination  port  number,  create  appropriate  server 
processes.  In  terms  of  pre-enpting  access  to  a  remote  terminal, 
however,  it  seems  more  sensible  to  let  the  process  which  interfaces  the 
terminal  to  the  system  mediate  the  pre-emption.  If  the  terminal  is  not 
connected  or  is  turned  off,  there  is  no  point  in  creating  a  process  to 
serve  the  incoming  high  precedence  connection  request. 

For  example,  suppose  a  routine  FTP  is  in  operation  between  Host  X  and 
Host  Y.  Host  Z  decides  to  do  a  flash- override  FTP  to  Host  X.  It  opens 
a  high  precedence  connection  via  its  TCP  and  the  'SYN"  goes  out  to  the 
FTP  port  on  Host  X- 

FTP  always  leaves  one  LISTEN  pending  to  pre-empt  lower  precedence  remote 
users  if  it  cannot  serve  one  more  user  (and  still  keep  a  LISTEN 
pending)  .  In  this  way,  the  FTP  is  naturally  in  a  state  permitting  the 
high  precedence  connection  request  to  be  properly  served,  and  the  FTP 
can  initiate  any  cleaning  up  that  is  needed  to  deal  with  the 
pre-enption. 

In  general,  this  strategy  permits  the  processes  using  TCP  to  accommodate 
pre-emption  in  the  context  of  the  applications  they  support. 

A  non-pre-enptable  process  is  one  that  does  not  have  a  LISTEN  pending 
while  it  is  serving  one  (or  more)  users. 

The  actions  taken  to  deal  with  pre-emption  of  TCP  connections  will  be 
application-process  specific  and  this  strategy  of  a  second  (or  N-^lst) 
LISTEN  is  well  suited  to  the  situation. 

Pre-emption  may  also  be  necessary  at  the  site  initiating  a  high 
precedence  connection  request.  Suppose  there  is  a  hi^  precedence  user 
who  wants  to  oper^an  FTP  connection  request  from  Host  Z  to  Host  X.  But 
all  FTP  and/or  TCP  resources  are  saturated  when  this  user  tries  to  start 
the  user  FTP  process.  In  this  case,  the  operating  system  would  have  to 
know  about  the  precedence  of  the  user  and  would  have  to  locally  pre-empt 
resources  on  his  behalf  (e.g.,  by  logging  out  lower  precedence  users) . 
This  is  a  system  issue,  not  specific  only  to  TCP.  Implementation  of 
pre-emption  at  the  source  could  vary  greatly.  Precedence  may  be 
associated  with  a  user  or  with  a  terminal .  The  TCP  implementation  may 
locally  pre-empt  resources  to  serve  high  precedence  users.  The 
operating  system  may  make  all  pre-emption  decisions. 
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This  memo  describes  the  relationship  between  the  Internet 

Protocol  (IP)  [1]  Typ>e  of  Service  and  the  service  parameters  of  specific 

networks . 

The  IP  Type  of  Service  has  the  following  fields: 

Bits  0-2:  Precedence. 

Bit  3:  0  =  Normal  Delay,  1  =  Low  Delay. 

Bits  4:  0  =  Normal  Throu^^^Hit,  1  =  High  Throug^iput. 

Bits  5:  0  =  Normal  Reliblllty,  1  =  High  Reliblllty. 

Bit  6-7:  Reserved  for  Future  Use. 

01234567 

•f - -f - -  +  -----4.- ----4.- - 4. - 4. - 

I  I  I  I  I  I  I 

I  PRECEDENCE  |  D  |  T  |  R  I  0  I  0 

1  I  I  I  I  I  I 

> - > - ^ - ^ - ^ - ^ - ^ - ^ - ^ 

111  -  Network  Control 

110  -  Internetwork  Control 

101  -  CRITIC/ECP 

100  -  Flash  Override 

Oil  -  Flash 

010  -  iBBiedlate 

001  -  Priority 

000  -  Routine 

The  Individual  networks  listed  here  have  very  different  and  specific 
service  choices. 
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AUTM)IN  II 

Ihe  service  choices  are  in  two  parts:  Traffic  Acceptance  Catagcries, 
and  Application  Type.  The  Traffic  Acceptance  Categories  can  be 
mapped  Into  and  out  of  the  IP  TOS  precedence  reasonably  directly. 

The  Application  types  can  be  mapp^  Into  the  remaining  IP  TOS  fields 
as  follows. 


TA 

DELAY 

THROUCSHPITT 

RELIABILITY 

I/A 

1 

0 

0 

Q/H 

0 

0 

0 

B1 

0 

1 

0 

B2 

0 

1 

1 

DTR 

TA 

000 

Q/R 

001 

Q/R 

010 

B1 

on 

B2 

100 

I/A 

101 

I/A 

no 

I/A 

111 

error 
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ARPANET 

Tt^e  service  choices  are  in  quite  limited.  There  is  one  priority  bit 
that  can  be  mapped  to  the  hig^  order  bit  of  the  IP  TOS  precedence. 
The  other  choices  are  to  use  the  regular  ("Type  0")  messages  vs.  the 
uncontrolled  ("Type  3")  messages,  or  to  use  single  packet  vs. 
multipacket  messages.  The  mapping  of  ARPANET  parameters  Into  IP  TOS 
parameters  can  be  as  follows. 

Type  Size  DELAY  THROUGHPUT  RELIABILITY 


0  S  1  0  0 

0  M  0  0  0 

3  S  1  0  0 

3  M  not  allowed 

DTR  Type  Size 

000  0  M 

001  0  M 

010  0  M 

oil  0  M 

100  3  S 

101  0  S 

110  3  S 

111  error 
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PRNET 


Hiere  is  no  priority  indication.  Hie  two  choices  are  to  use  the 
station  routing  vs.  point-to-point  routing,  or  to  require 
acknowledgments  vs.  having  no  acknowledgments.  The  mapping  of  PRNET 
parameters  into  IP  'fOS  parameters  can  be  as  follows. 


Routing 


DELAY 


THROUGHPUT 


RELIABILITY 


ptp 

no 

pty 

yes 

station  no 

( 

station  yes 

1 

DTR 

Routing 

Acks 

000 

station 

no 

001 

station 

yes 

010 

station 

no 

Oil 

station 

yes 

100 

ptp 

no 

101 

ptp 

yes 

110 

pt?> 

no 

111 

PQ> 

yes 

SATNET 

There  is  no  priority  indication.  The  four  choices  are  to  use  the 
block  vs.  stream  type,  to  select  one  of  four  delay  catagories,  to 
select  one  of  two  holding  time  strategies,  or  to  request  one  of  three 
reliability  levels.  The  mapping  of  SATNET  parameters  into  IP  TOS 
parameters  can  thus  quite  complex  there  being  2*4*2*3=48  distinct 
possibilities. 
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Internet  Addresses 


Thic - dcccribcc  the  relationship  between  address  fields  used  in 

the  Internet  Prococol  (IF)  [1]  and  several  specific  networks. 

An  internet  address  is  a  32  bit  quantity,  with  several  codings  as 
shown  below. 

The  first  type  (or  class  a)  of  address  has  a  7 -bit  network  number  and 
a  24-bit  local  address. 

12  3 

01234567890123456789012345678901 

+  -  +  -  +  -  +  -  +  -  +  -  +  -  +  +  -  +  -  +  - 4--  +  -  +  - +  -  +  - +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  + 

jOI  NETWORK  1  Local  Address  1 

Class  A  Address 

The  second  type  (or  class  b)  of  address  has  a  14-bit  network  number 
and  a  16-bit  local  address. 

12  3 

0123456789012345678901234  5  678901 
+  +  _  +  _  +  _  +  _  +  4. +  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  + 

jl  0|  NETWORK  i  Local  Address  1 

+  _  +  _  4.-.  +  +  +  _  +  _  +  +  _  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  + 


Class  B  Address 

The  third  type  (or  class  c)  of  address  has  a  21-bit  network  number 
and  a  8-bit  local  address. 

12  3 

0123456789012345678901234567890  1 

+  -  +  -  +  -  +  -  +  -  f-  +  -+-  +  -  +  -+-  +  -  +  -  +  -  +  -H  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  +  -  + -  +  + 

|1  1  0|  NETWORK  I  Local  Address  | 

+  -  +  -  +  -  +  +  -  +  -  +  +  -  +  -  +  -  +  -  +  “  +  +  -  +  -  +  -  +  -  +  -  +  +  -  +  -  + 

Class  C  Address 

The  local  address  carries  information  to  address  a  host  in  the 
network  identified  by  the  network  number.  Since  each  network  has  a 
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particular  address  format  and  length,  the  following  section  describes 
the  mapping  between  internet  local  addresses  and  the  actual  address 
format  used  in  the  particular  network. 

Internet  to  Local  Net  Address  Mappings 


The  following  transformations  are  used  to  convert  internet  addresses 
to  local  net  addresses  and  vice  versa: 

AUTODIN  II 


The  AJTODIN  II  has  16  bit  subscriber  addresses  which  identify 
either  a  host  or  a  terminal.  These  addresses  may  be  assigned 
independent  of  location.  The  16  bit  AUTODIN  II  address  is 
located  in  the  24  bit  internet  local  address  as  shown  below. 

The  network  number  of  the  AUTODIN  II  is  26  (Class  A)  . 

+ - + 

I  HOST/TERMINAL  |  AUTODIN  II 

+ - + 

16 

+ - + - + - + - a. 

I  26  j  ZERO  i  HOST/'TERMINAL  ]  IP 

4 - + - + - + - + 

8  8  16 
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ARPANET 


The  ARPANET  (with  96  bit  leaders)  has  24  bit  addresses.  The  24 
bits  are  assigned  to  host,  logical  host,  and  IMP  leader  fields 
as  illustrated  below.  These  24  bit  addresses  are  used  directly 
for  the  24  bit  local  address  of  the  internet  address.  However, 
the  ARPANET  IMPs  do  not  yet  support  this  form  of  logical 
addressing  so  the  logical  host  field  is  set  to  zero  in  the 
leader . 

The  network  number  of  the  ARPAIJET  is  10  (Class  A)  . 

+ - + - + - + 

1  HOST  i  ZERO  I  IMP  I  ARPANET 

+ - + - + - + 

8  8  8 

+ - + - + - + - + 

I  10  I  HOST  I  LH  I  IMP  I  IP 

+ - + - + - + - + 

8  8  8  8 

DCNs 


The  Distributed  Conputing  Networks  (DCNs)  at  COMSAT  and  UCL  use 
16  bit  addresses  divided  into  an  8  bit  host  identifier  (HID) , 
and  an  8  bit  process  identifier  (PID)  .  The  format  locates 
these  16  bits  in  the  low  order  16  bits  of  the  24  bit  internet 
address,  as  shown  below. 

The  network  number  of  the  COMSAT-DCN  is  29  (Class  A) ,  and  of 
the  UCL-IXT^  is  30  (Class  A)  . 

+ - + - + 

I  HID  I  PID  I  DCN 

+ - + - + 

8  8 

+ - + - + - + - + 

I  18  I  ZERO  I  HID  I  PID  |  IP 

+ - + - 'f- - + - + 

8  8  8  8 


Postel 


[Page  3] 


DDN  PROTOCOL  IL^VNDBOOK  -  VOLUME  THREE 


1985 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1985 


RFC  796 


September  1981 
Address  Mappings 


SATNET 


Hie  Atlantic  Satellite  Packet  Network  has  16  bit  'ddresses  for 
hosts.  These  addresses  may  be  assigned  Independent  of  location 
(i.e.,  ground  station) .  It  is  also  possible  to  assign  several 
addresses  to  one  physical  host,  so  the  addresses  are  logical 
addresses.  The  16  bit  SATNET  address  is  located  in  the  24  bit 
internet  local  address  as  shown  below. 

The  network  number  of  the  SATNET  Is  4  (Class  A)  . 


1 

HOST 

-+ 

1 

SATNET 

16 

1 

4 

1  ZERO 

1 

M  ^  M  a 

HOST 

w  w  w  ^ 

1 

«  aa  «  ^ 

IP 

8 

8 

•  ▼  •  • 

16 

«  aa 

WBCNET 


The  Wid^and  Communication  Satellite  Packet  Network  (WBCNET) 
Host  Access  Protocol  (HAP)  has  16  bit  addresses  for  hosts.  It 
is  possible  to  assign  several  addresses  to  one  physical  host, 
so  the  addresses  are  logical  addresses.  The  16  bit  WBCNET 
address  is  divided  into  a  HAP  Number  field  and  a  Local  Address 
field,  and  is  located  in  the  24  bit  internet  local  address  as 
shown  below.  Please  see  [2]  for  more  details. 

The  network  number  of  the  WBCNET  is  28  (Class  A)  . 

-► - + - + 

I  HAP  NUM|  LCL  ADD)  WBCNET 

^ - + - ^ 

8  8 

^ - ^ - ^ - + - + 

I  28  I  HAP  NUM|  ZERO  |  LCL  ADD|  IP 

^ - ^ - ^ - ^ - ^ 

8  8  8  8 
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DOD  INTERNET  HOST  TABLE  SPECIFICATION 


STATUS  OF  THIS  MEMO 

This  RFC  is  the  official  specification  of  the  format  of  the  Internet 
Host  Table.  Ihis  edition  of  the  specification  includes  minor 
revisions  to  RFC-810  which  brings  it  up  to  date.  Distribution  of  this 
memo  is  unlimited. 


INTRODUCTION 

The  DoD  Host  Table  is  utilized  by  the  DoD  Hostname  Server  maintained 
by  the  DDN  Network  Information  Center  (NIC)  on  b^alf  of  the  Defense 
Communications  Agency  (DCA)  [See  RFC- 953]  . 

LOCATION  OF  THE  STANDARD  DOD  ONLINE  HOST  TABLE 

A  machine-translatable  ASCII  text  version  of  the  DoD  Host  Table  is 
online  in  the  file  NETINFO:  HOSTS.  TXT  on  the  SRI -NIC  host.  It  can  be 
obtained  via  FTP  from  your  local  host  by  connecting  to  host 
SRI-NIC.ARPA  (26.0.0.73  or  10.0.0.51),  logging  in  as  user  = 

ANONYMOUS,  password  =  GUEST,  and  retrieving  the  file 
•‘NETINFO :H0STS. TXT".  The  same  table  may  also  be  obtained  via  the  NIC 
Hostname  Server,  as  described  in  RFC- 953.  The  latter  method  is 
faster  and  easier,  but  requires  a  user  program  to  make  the  necessary 
connection  to  the  Name  Server. 


ASSUMPTIONS 

1.  A  "name"  (Net,  Host,  Gateway,  or  Domain  name)  is  a  text  string  up 
to  24  characters  drawn  from  the  alphabet  (A-Z) ,  digits  (0-9) ,  minus 
sign  (-) ,  and  period  (.)  .  Note  that  periods  are  only  allowed  when 
they  serve  to  delimit  conponents  of  "domain  style  names".  (See 
RFC-921,  "Domain  Name  System  Implementation  Schedule",  for 
background)  .  No  blank  or  space  characters  are  permitted  as  part  of  a 
name.  No  distinction  is  made  between  upper  and  lower  case.  The  first 
character  must  be  an  alpha  character.  The  last  character  must  not  be 
a  minus  sign  or  period.  A  host  which  serves  as  a  GATEWAY  should  have 
"-GATEWAY"  or  "-GW"  as  part  of  its  name.  Hosts  which  do  not  serve  as 
Internet  gateways  should  not  use  "-GATEWAY"  and  "-GW"  as  part  of 
their  names.  A  host  which  is  a  TAC  should  have  "-TAC"  as  the  last 
part  of  its  host  name,  if  it  is  a  DoD  host.  Single  character  names 
or  nicknames  are  not  allowed. 

2.  Internet  Addresses  are  32-bit  addresses  [See  RFC-796].  In  the 
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host  table  described  herein  each  address  is  represented  by  four 
decimal  numbers  separated  by  a  period.  Each  decimal  number 
represents  1  octet. 

3.  If  the  first  bit  of  the  first  octet  of  the  address  is  0  (zero), 
then  the  next  7  bits  of  the  first  octet  indicate  the  network  numloer 
(Class  A  Address) .  If  the  first  two  bits  are  1,0  (one, zero),  then 
the  next  14  bits  define  the  net  number  (Class  B  Address)  .  If  the 
first  3  bits  are  1,1,0  (one, one, zero) ,  then  the  next  21  bits  define 
the  net  number  (Class  C  Address)  [See  RFC- 943] . 

This  is  depicted  in  the  following  diagram: 


NET  <-7-> 


LOCAL  ADDRESS  <-24-> 


<-14-> 


LOCAL  ADDRESS  <-16-> 


NET  <-21-> 


LOCAL  ADDRESS 


4.  Ihe  LOCAL  ADDRESS  portion  of  the  internet  address  identifies  a 
host  within  the  network  specified  by  the  NET  portion  of  the  address. 

5.  The  ARPANET  and  MILNET  are  both  Class  A  networks.  Ihe  NET  portion 
Is  10  decimal  for  ARPANET,  26  decimal  for  MILNET,  and  the  LOCAL 
ADDRESS  maps  as  follows:  the  second  octet  identifies  the  physical 
host,  the  third  octet  Identifies  the  logical  host,  and  the  fourth 
identl  f ies  the  Packet  Switching  Node  (PSN) ,  formerly  known  as  an 
Interface  Message  Processor  (IMP) . 


10  or  26 


I  LOGICAL  HOSl’ 


PSN  (IMP) 


(NOTE:  RFC-796  also  describes  the  local  address  mappings  for 
several  other  networks.) 

6.  It  is  the  responsibility  of  the  users  of  tliis  host  table  to 
translate  it  into  whatever  format  is  needed  for  their  purposes. 

7.  Names  and  addresses  for  DoD  hosts  and  gateways  will  be  negotiated 
and  registered  with  the  DDN  PMO,  and  subsequently  with  the  NIC, 
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before  being  used  and  before  traffic  is  passed  by  a  DoD  host.  Names 
and  addresses  for  domains  and  networks  are  to  be  registered  with  the 
DDN  Network  Information  Center  (H0S1MASTER@SRI-NIC.ARPA)  or 
800-235-3155. 

The  NIC  will  attempt  to  keep  similar  Information  for  non-DoD  networks 
and  hosts,  if  this  information  is  provided,  and  as  long  as  it  is 
needed,  i.o.,  until  intercommunicating  network  name  servers  are  in 
place . 

EXAMPLE  OF  HOST  TABLE  FORMAT 

NET  :  10.0.0.0  :  ARPANET  : 

NET  ;  128.10.0.0  :  PURDUE-CS-NET  : 

GATEWAY  ;  10.0.0.77,  18.10.0.4  :  MIT-GW.ARPA, MIT-GATEWAY  :  PDP-11  : 
MOS  ;  IP/GW, ECy  : 

HOST  ;  26.0.0.73,  10.0.0.51  :  SRI -NIC.  ARPA,  SRI -NIC,  NIC  :  DEC-2060  : 

T0PS20  :TCP/TELNET,TCP/SMIP,TCPAI^®.'I^/^^TCP/ECHD,ICMP  : 
HOST  :  10.2.0.11  :  SU-TAC.ARPA,SU-TAC  :  C/30  :  TAC  :  TCP  : 

SYNTAX  AND  CONVENTIONS 

;  (semicolon)  is  used  to  denote  the  beginning  of  a  comment. 

Any  text  on  a  given  line  following  a  ' ;  ’  is  a 
comment,  and  not  part  of  the  host  table. 

keyword  introducing  a  network  entry 

keyword  Introducing  a  gateway  entry 

keyword  Introducing  a  host  entry 

keyword  introducing  a  domain  entry 

is  used  a^  a  field  delimiter 

indicates  a  null  field 

is  used  as  a  data  element  delimiter 

indicates  protocol  information  c '  the  type 
TRANSPORT/SERVICE . 

where  TRANSPORT/SERVICE  options  are  specified  as 
"FOO/BAR"  both  transport  and  service  known 


NET 

GATEWAY 
HOST 
DOMAIN 
:  (colon) 

: :  (2  colons) 
,  (comma) 
XXX/YYY 
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"FOO"  transport  known;  services  not  known 

"BAP."  service  is  known,  transport  not  known 

NOTE:  See  "Assigned  Numbers"  for  specific  options  and  acronyms 
for  machine  types,  operating  systems,  and  protoco  1 /services . 

Each  host  table  entry  is  an  ASCII  text  string  coiqprised  of  6  fields, 
where 

Field  1  KEYWORD  indicating  whether  this  entry  pertains  to 

a  NET,  GATEWAY,  HOST,  or  DOMAIN.  NET  entries  are 
assigned  and  cannot  have  alternate  addresses  or 
nicknames.  DOMAIN  entries  do  not  use  fields  4,  5, 
or  6. 

Field  2  Internet  Address  of  Network,  Gateway,  or  Host 

followed  by  alternate  addresses.  Addresses  for  a 
Domain  are  those  where  a  Domain  Name  Server  exists 
for  that  domain. 

Field  3  Official  Name  of  Network,  Gateway,  Host,  or  Domain 

(with  optional  nicknames,  where  permitted)  . 

Field  4  Machine  Type 

Field  5  Curating  Syst^ 

F.leld  6  Protocol  List 

Fields  4,  5  and  6  are  optional.  For  a  Domain  they  are  not  used. 

Fields  3-6,  if  included,  pertain  to  the  first  address  in  Field  2. 

'Blanks'  (spaces  and  tabs)  are  Ignored  between  data  elements  or 
fields,  but  are  disallowed  within  a  data  element. 

Each  entry  ends  with  a  colon. 

The  entries  in  the  table  are  grouped  by  types  in  the  order  Domain, 
Net,  Gateway,  and  Host.  Within  each  type  the  ordering  is 
unspecified. 

Note  that  although  optional  nicknames  are  allowed  for  hosts,  they  are 
discouraged,  except  in  the  case  where  host  names  have  been  chang^ 
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and  both  the  new  and  the  old  names  are  maintained  for  a  suitable 
period  of  time  to  effect  a  smooth  transition.  Nicknames  are  not 
permitted  for  NET  names. 

GRAi^WATICAL  HC'T  TABLE  SPECIFICATION 


A.  Parsing  grammar 

<entry>  :  <keyword>  **:  *'  <addresses>  <names>  [*':*'  [<cputype>] 

[<qpsys>]  [<protocol  list>]  ]]] 

<addresses>  ::=  <address>  *[‘'/'  <address>] 

<address>  :  <octet>  <octet>  <octet>  <octet> 

<octet>  <0  to  255  declmal> 

<namos>  :  <netname>  |  <gatename>  |  <domainname> 

<nickn£imes>] 

I  <official  hostname>  <nicknames>] 

<netname>  :  <name> 

<9mt«name>  : <hname> 

<domainnaiDe>  : :  >  <hnaine> 

<official  hostname>  :  :=  <linamo> 

<nicknaine>  :  :=  <hname> 

<protocol  list>  :  :=  <protocol  spec>  *[*'/'  ^protocol  spec>] 
<protocol  spec>  :  :=  <transport  naxoe>  V”  <service  narae> 

I  <raw  protocol  name> 

B.  Lexical  grammar 

<entry- f leld>  :  <ontry-text>  [<cr><lf>  <blank>  <entry- field>3 

<entry-tQxt>  : :=  <prlnt-char>  *<text> 

<blank>  :  :=  <spaco-or-tab>  [<blank>] 

<keyword>  :  NET  |  GATEWAY  |  HOST  |  DOMAIN 
<hname>  :  :=  <nanie'>*  ['* .  ”<name>] 

<name>  <let>[*  [<let-or-digit-or-hyphen>]<let-or-dlgit>] 

<cputype>  ::=  PDP-11/70  |  DEC- 1080  |  C/30  |  CDC-6400 . . .etc. 
<opsys>  ITS  |  MULTICS  |  T0PS20  |  UNIX... etc. 

<transport  name>  : TCP  |  NCP  |  UDP  j  IP. . .etc. 

<servlce  naiBe>  :  TELNET  j  FTP  |  SMTP  |  MTP.-.etc. 

<rav  protocol  name>  : :  =:  <name> 

<coiBDent>  :  <text><cr><lf> 

<text>  ; :=  * [<print-char>  |  <blank>] 

<print-char>  :  <any  printing  char  (not  space  or  tab)  > 

Notes : 


1.  Zero  or  more  'blanks'  between  separators  ",  :  "  are  allowed. 
'Blanks'  are  spaces  and  tabs. 
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2.  Continuation  lines  are  lines  that  begin  with  at  least  one 
blank.  They  may  be  used  anywhere  'blanks'  are  legal  to  split  an 
entry  across  lines. 
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Introduction 

In  an  attenpt  to  provide  online  documents  to  the  network  community  we 
have  had  many  problems  with  the  physical  format  of  the  final 
documents.  Much  of  this  difficulty  lies  in  the  fact  that  we  do  not 
have  control  or  even  knowledge  of  all  the  processing  steps  or  devices 
that  act  on  the  document  file.  A  large  part  of  the  difficulty  in  the 
past  has  been  due  to  some  assunptions  we  made  about  the  rest  of  the 
world  being  approximately  like  our  own  environment.  We  now  see  that 
the  problems  are  due  to  differing  assumptions  and  treatment  of  files 
r.o  be  printed  as  documents.  We  therefore  propose  to  define  certain 
standard  formats  for  files  and  describe  the  expected  final  form  for 
printed  copies  of  such  files. 

These  standard  formats  are  not  additional  File  Transfer  Protocol  data 
types/modes/structures,  but  rather  usage  descriptions  between  the 
originator  and  ultimate  receiver  of  the  file.  It  may  be  useful  or 
even  necessary  at  some  hosts  to  construct  programs  that  convert  files 
between  common  local  formats  and  the  standard  formats  specified  here. 

The  intent  is  that  the  author  of  a  document  may  prepare  his/her  text 
and  store  it  in  an  online  file,  then  advertise  that  file  by  name  and 
format  (as  specified  here) ,  such  that  interested  individuals  may  copy 
and  print  the  file  with  full  understanding  of  the  characteristics  of 
the  format  controls  and  the  logical  page  size. 

Standardization  Elements 

The  elements  or  aspects  of  a  file  to  be  standardized  are  the 
character  or  code  set  used,  the  format  control  procedures,  the  area 
of  the  page  to  be  used  for  text,  and  the  method  to  describe 
overstruck  or  underlined  characters. 

The  area  of  the  page  to  be  used  for  text  can  be  confusing  to  discuss, 
in  an  attenpt  to  be  clear  we  define  a  physical  page  and  a  logical 
page.  Please  note  that  the  main  enphasis  of  this  note  is  to  describe 
the  standard  formats  in  terms  of  the  logical  page,  and  that  it  is  up 
to  each  site  to  map  the  logical  page  onto  the  physical  page  of  each 
of  their  devices. 
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Physical  Page 

The  physical  page  is  the  medium  that  carries  the  text,  the 
height  and  width  of  its  area  are  measured  in  inches. 

The  typical  physical  page  is  a  piece  of  paper  eleven  inches 
hig^  and  eight  and  one  half  inches  wide. 

Typical  print  density  is  10  characters  per  inch 
horizontally  and  6  characters  per  inch  vertically.  This 
results  in  the  typical  physical  page  having  a  maximum 
capacity  of  66  lines  and  85  characters  per  line.  It  is 
often  the  case  that  printing  devices  limit  the  area  of 
the  physical  page  by  enforcing  margins. 

Logical  Page 

The  logical  page  is  the  area  that  can  contain  text,  the  height 
of  this  area  is  measured  in  lines  and  the  width  is  measured  in 
characters . 

A  typical  logical  page  is  60  lines  higfi  and  72  characters 
wide. 

Code  Set 

The  character  encoding  will  be  the  network  standard  Network 
Virtual  Terminal  (NVT)  code  as  used  in  Telnet  and  File  Transfer 
protocols,  that  is  ASCII  in  an  eight  bit  byte  with  the  high  order 
bit  zero. 

Format  Control 

The  format  will  be  controlled  by  the  ASCII  format  effectors: 

Form  Feed  <FF> 

Moves  the  printer  to  the  top  of  the  next  logical  page 
keeping  the  same  horizontal  position. 

Carriage  Return  <CR> 

Moves  the  printer  to  the  left  edge  of  the  logical  page 
remaining  on  current  line. 
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Line  Feed  <LF> 

Moves  the  printer  to  the  next  print  line,  keeping  the  same 
horizontal  position. 

Horizontal  Tab  <HT> 

Moves  the  printer  to  the  next  horizontal  tab  stop. 

The  conventional  stops  for  horizontal  tabs  are  every 
eig^bt  characters,  that  is  character  positions  9,  17,  25, 

. . .  ■  within  the  logical  page . 

Note  that  it  is  difficult  to  enforce  these  conventions  and 
it  is  therefore  recommended  that  horizontal  tabs  not  be  used 
in  document  files. 

Vertical  Tab  <VT> 

Moves  the  printer  to  the  next  vertical  tab  stop. 

The  conventional  stops  for  vertical  tabs  are  every  eight 
lines  starting  at  the  first  printing  line  on  each  logical 
page,  that  is  lines  1,  9,  17,  ...  within  the  logical 
page. 

Note  that  it  is  difficult  to  enforce  these  conventions  and 
it  is  therefore  recommended  that  vertical  tabs  not  be  used 
in  dcxiument  files. 

Back  Space  <BS> 

Moves  the  printer  one  character  position  toward  the  left 
edge  of  the  logical  page. 

Not  all  these  effectors  will  be  used  in  all  format  standards,  any 
effectors  %^ich  are  not  uscjd  in  a  format  standard  are  Ignored. 


Page  Length 

The  logical  page  length  will  be  specified  in  terms  of  a  number  of 
lines  of  text. 
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Standard  Formats 

Format  1  [Basic  Document] 

This  format  is  designed  to  be  uised  for  documents  to  be  printed  on 
line  printers,  which  normally  have  66  lines  to  a  physical  page, 
but  often  have  forced  top  and  bottom  margins  of  3  lines  each. 

Active  Format  Effectors 
<FF>,  <CR>,  <LF>. 

Page  Length 
60  lines. 

Page  Width 

72  Characters. 

Over  striking 
By  Line. 

Format  2  [Terminal] 

This  format  is  designed  to  be  used  with  hard  copy  terminals,  which 
in  the  normal  case  have  66  lines  to  a  physical  page.  It  is 
esqpected  that  there  are  no  top  or  bottom  margins  enforced  by  the 
terminal  or  its  local  system,  thus  any  margins  around  the  physical 
page  break  must  come  from  the  file. 

Active  Format  Effectors 

<FF>,  <CR>,  <LF>,  <Hr>,  <VT>,  <BS>. 

Page  Length 
66  lines. 

Page  Width 

72  Characters. 

Over  striking 
By  Character. 
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Format  3  [Line  Printer] 

This  format  is  designed  to  be  used  with  full  width  (11  by  14  inch 
paper)  line  printer  output. 

Active  Format  Effectors 
<FF>,  <CR>,  <LF>. 

Page  Length 
60  lines. 

Page  Width 

132  Characters. 

Overstriking 

None. 

Format  4  [Card  Image] 

This  format  is  designed  to  be  used  for  simulated  card  input.  The 
page  width  is  80  characters,  each  card  image  is  followed  by 
<CR><LF>,  thus  each  card  is  r^resented  by  between  2  and  82 
characters  in  the  file.  Note  that  the  trailing  spaces  of  a  card 
image  need  not  be  present  in  the  file,  and  that  the  early 
occurence  of  the  <CR><LF>  sequence  indicates  that  the  remainder  of 
the  card  image  is  to  contain  space  characters. 

Active  Format  Effectors 
<CR>,  <LF>. 

Page  Length 
Infinite. 

Page  Width 

80  Characters. 

Over striking 
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Format  5  [Center  Document] 

ITiis  format  is  intended  for  use  with  documents  to  be  printed  on 
line  printers  which  normally  have  66  lines  to  the  physical  page 
but  enforce  top  and  bottom  margins  of  3  lines  each.  Ihe  text  is 
expected  to  be  centered  on  the  paper.  If  the  horizontal  printing 
density  is  10  characters  per  inch  and  the  paper  is  8  and  1/2 
inches  wide  then  there  will  be  a  one  inch  margin  on  each  side. 

Active  Format  Effectors 
<FF>,  <CR>,  <LF>. 

Page  Length 
60  Lines. 

Page  Width 

65  Characters. 

Over striking 
By  Line. 

Format  6  [Bound  Document] 

Tliis  format  is  intended  for  use  with  documents  to  be  printed  on 
line  printers  \rtiich  normally  have  66  lines  to  the  physical  page 
but  enforce  top  and  bottom  margins  of  3  lines  each.  If  the 
horizontal  printing  density  is  10  characters  per  inch  and  the 
paper  is  8  and  1/2  inches  wide  then  the  text  should  be  positioned 
such  that  there  is  a  1  and  1/2  inch  left  margin  and  a  one  inch 
ri9(ht  margin. 

Active  Format  Effectors 
<FF>,  <CR>,  <LF>. 

Page  Length 
60  Lines. 

Page  Width 

60  Characters. 

Overstriking 
By  Line. 
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Implementation  Suggestions 
Overflow 

Overflow  can  result  from  two  causes,  first  if  the  physical  page  is 
smaller  than  the  logical  page,  and  second  if  the  actual  text  in 
the  file  violates  the  standard  under  which  it  is  being  processed. 

In  either  case  the  following  suggestions  are  made  to  implementors 
of  programs  which  process  files  in  these  formats. 

Length 

If  more  lines  are  processed  than  fit  within  the  minimum  of  the 
physical  page  and  the  logical  page  length  since  the  last  <FF>, 
then  the  <FF>  action  should  be  forced. 

Width 

If  more  character  positions  are  processed  than  fit  on  the 
minimum  of  the  physical  page  width  and  the  logical  page  width 
since  the  last  <CR>,  then  characters  are  discarded  \jp  to  the 
next  <CR>, 

or 

If  more  character  positions  are  processed  than  fit  on  the 
minimum  of  the  physical  page  width  and  the  logical  page  width 
since  the  last  <CR>,  then  the  <CR>  and  <LF>  actions  should  be 
forced , 

References 

A.  McKenzie  "TELNET  Protocol  Specification,"  Aug-73,  NIC  18639. 

"USA  Standard  Code  for  Information  Interchange, "  United  States  of 
America  Standards  Institute,  1968,  NIC  11246. 


APPENDICES 


INSTRUCTIONS  FOR  AUTHORS  OF  RFCs 


RFCs  are  distributed  online  by  being  stored  as  public  access  files,  and 
a  short  messages  is  sent  to  the  distribution  list  indicating  the 
availability  of  the  memo. 

The  online  files  are  copied  by  the  interested  people  and  printed  or 
displayed  at  their  site  on  their  equipment.  This  means  that  the  format 
of  the  online  files  must  meet  the  constraints  of  a  wide  variety  of 
printing  and  display  equipment. 

To  meet  these  constraints  the  following  rules  are  established  for  the 
format  of  RFCs; 

The  character  codes  are  ASCI I . 

Each  page  must  be  limited  to  58  lines  followed  by  a  form  feed  on  a 
line  by  itself. 

Each  line  must  be  limited  to  72  characters  followed  by  carriage 
return  and  line  feed. 

No  overstr iking  (or  underlining)  is  allowed. 

These  "hei^^t”  and  "width"  constraints  include  any  headers,  footers, 
page  numbers,  or  left  side  indenting. 

Each  RFC  is  to  include  on  its  title  page  or  in  the  first  or  second 
paragraph  a  statement  (titled  "Status  of  this  Memo")  describing  the 
intention  of  the  RFC.  There  are  several  reasons  for  publishing  a  memo 
as  an  RFC,  for  example,  to  make  available  some  information  for 
Interested  people,  or  to  begin  or  continue  a  discussion  of  an 
interesting  idea,  or  to  make  available  the  specification  of  a  protocol . 

The  following  sasple  paragraphs  may  be  used  to  satisfy  this 
requirement : 

Specification 

This  RFC  specifies  a  standard  for  the  DARPA  Internet  community 
Hosts  on  the  ARPA- Internet  are  eaqpocted  to  adc^t  and  implement 
this  standard. 

Discussion 

The  purpose  of  this  RFC  is  to  focus  discussion  on  particular 
problems  in  the  ARPA- Internet  and  possible  methods  of  solution 
No  proposed  solutions  this  document  are  Intended  as  standards 
for  the  ARPA- Internet.  Rather,  it  is  hoped  that  a  general 
consensus  will  emerge  as  to  the  appropriate  solution  to  such 
problems,  leading  eventually  to  the  adoption  of  standards. 

Information 

This  RFC  is  being  distributed  to  members  of  the  ARPA- Internet 
community  in  order  to  solicit  their  reactions  to  the  proposals 
contained  in  it.  While  the  issues  discussed  may  not  be 
directly  relevant  to  the  research  problems  of  the 
ARPA- Internet,  they  may  be  interesting  to  a  number  of 
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researchers  and  inplementers . 

Status 

In  response  to  the  need  for  maintenance  of  current  information 
about  the  status  and  progress  of  various  projects  in  the 
ARPA- Internet  community,  this  RFC  is  issued  for  the  benefit  of 
community  members.  The  information  contained  in  this  document 
is  accurate  as  of  the  date  of  publication,  but  is  subject  to 
change.  Subsequent  RFCs  will  reflect  such  changes. 

Of  course  these  paragraphs  need  not  be  followed  word  for  word,  but 
the  general  intent  of  the  RFC  must  be  made  clear. 

Each  RFC  is  to  also  include  a  "distribution  statement" .  In  general  RFCs 
have  unlimited  distribution.  There  may  be  a  few  cases  in  which  it  is 
appropriate  to  restrict  the  distribution  in  some  way. 

Typically  the  distribution  statement  will  simply  be  the  sentence 
"Distribution  of  this  memo  is  unlimited."  appended  to  the  "status  of 
this  memo"  section. 


rm 
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RFC  797 


Network  Working  Group  A.  Katz 

Request  for  Comments:  797  I SI 

September  1981 


FORMAT  FOR  BIIMAP  FILES 

This  note  describes  a  proposed  format  for  storing  simple  bitmaps  (one 
bit  per  pixel)  in  a  file.  These  files  may  be  very  large  and  the 
intent  is  to  use  this  format  for  short  term  storage  and  passing  data 
between  closely  coupled  programs.  The  data  in  the  file  should  be 
stored  in  8-bit  bytes  (octets)  .  Bitmaps  may  be  any  size. 

The  first  4  octets  of  the  file  gives  the  width  of  each  line  (x 
direction)  ,  and  the  next  4  octets  should  give  the  number  of  lines  of 
the  display  (length,  y  direction)  .  After  this  is  one  octet  for  the  x 
increment  and  one  octet  for  the  y  increment.  Following  these  10 
octets  is  the  bitmap  itself.  The  length  and  width  fields  are 
stored  most  significant  octet  first. 

The  X  and  y  increment  octets  tell  how  much  space  is  between  pixels. 
For  an  ordinary  display,  both  these  wou3d  be  one. 

Each  line  of  the  display  should  be  scanned  from  left  to  right.  The 
lines  should  start  at  the  top  and  work  down.  Each  line  in  the  bitmap 
should  end  on  an  octet  boundary.  If  the  width  of  the  di^lay  is  not 
divisable  by  8,  the  rest  of  the  last  octet  should  be  filled  with 
zeros  on  the  right. 

Below  is  a  representation  of  a  bitmap  file  (each  square  is  one 
octet) : 


1 

1 

1 

width 

2 

width 

3  1 

width  1 

4 

width 

1  s  1 

1  length  | 

1 

6 

7 

8  1 

9 

1  10  1 

1 

length 

length 

length  | 

x- increment 

1  y- Increment  1 

1 

11 

12 

13 

14 

1  15 

1 

data 

1  data 

data  1 

data 

1  data . . . 

For  exanple,  bitmaps  from  the  RAPICOM  450  can  be  in  Fine  Detail, 
Quality,  or  Express  Mode.  In  Fine  Detail  mode  the  x- Increment  and 
y- increment  would  be  1,  for  Quality  mode,  the  x- increment  would  be  1 
and  the  y- increment  would  be  2,  and  for  Express  mode,  the  x- increment 
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would  be  1  and  the  y- increment  would  be  3.  For  these  bitmaps  it  is 
intended  that  each  scan  line  be  repeated  y- increment  times  when  they 
are  displayed. 
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RPC  769 


Network  Working  Group  J  •  Postel 

Request  for  Comments:  769  ISI 

26  September  1980 


Rapicom  450  Facsimile  File  Format 


Introduction : 

Several  organizations  in  the  ARPA  Internet  community  have  RAPICOM  450 
facsimile  machines  interfaced  to  computers.  This  allows  these 
organizations  to  «nter  a  facsimile  representation  of  a  page  into  a 
computer  file,  and  to  produce  a  page  from  stored  facsimile  data.  These 
organizations  can  exchange  stored  facsimile  data  via  file  transfer  and 
other  protocols.  The  purpose  of  this  note  is  to  document  the  format 
used  for  these  files  so  that  other  organizations  with  compatible 
facsimile  devices  can  Join  in  this  information  exchange  procedure. 

The  Rapicom  450: 

The  Rapicom  450  has  a  built  in  encoding/decoding  scheme.  It  produces 
data  blocks  of  585  bits.  There  are  "set  up"  blocks  and  "data"  blocks. 
The  machine  sends/receives  several  copies  of  the  set  up  block,  but  since 
they  are  identical  only  one  set  up  block  is  stored  in  the  file. 

Records : 

Each  585  bit  block  is  placed  in  a  record  of  8-bit  bytes.  The  record 
format  is  a  length  byte,  a  command  byte  and  the  data  bytes.  Each  record 
is  an  integral  number  of  bytes.  The  length  value  includes  the  Iwgth 
byte  and  the  command  byte.  The  command  describes  the  data  in  the  data 
field. 


0123  length 

+ - - + - > - ♦ — // — ^ - ♦ - 

I  length  |  command  |  data  I 

-*• . . + . > . ♦ — //---♦ . . 

Rapicom  450  Facsimile  Record 

Commands: 

56  -  SET-UP 

The  command  code  56  (70  octal)  Indicates  the  following  data  field  is  a 
set  up  block. 
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Raplcom  450  Facsimile  File  Format 


26  September  1980 
RFC  769 


Ihe  command  code  57  (71  oct^^l)  indicates  the  following  data  field  is  a 
data  block. 

58  -  END 

The  command  code  58  (72  octal)  indicates  that  this  is  the  last  record 
in  the  file.  In  this  case  the  length  may  be  2,  Indicating  that  there 
is  no  data  in  this  record. 

Conventions : 

In  the  files  exchanged  to  date,  each  record  contains  one  block.  This 
means  the  data  field  is  74  bytes  long  (585/8=73.125),  and  the  lengtn 
field  has  the  value  76  (114  octal) ,  except  the  last  record  which  may 
carry  no  data  and  have  a  length  of  2. 

The  first  record  of  a  file  is  always  a  SET  UP  record,  the  following 
records  are  DATA  records,  until  the  last  record  which  is  an  END  record. 

Details : 

The  585  bit  dfita  block  is  encoded  by  the  Raplcom  450  and  so  can  not  be 
used  a  bit  map  unless  the  encoding/decoding  procedure  is  known  and  used. 

The  first  24  bits  of  the  block  is  always  a  synchronization  mark  with  the 
value  271  141  344  in  octal  or  101110010110000111100100  in  binary. 

The  low  order  two  bits  of  the  rext  byte  contain  a  sequence  number 
(modulo  4) .  The  sequence  number  bits  cycle  in  the  order  11,  01,  10,  00, 
starting  with  the  first  DATA  record  (not  the  SET  UP  record)  . 

The  line  below  represents  a  DATA  record,  where  L  represents  a  length 
bit,  C  represents  a  command  bit,  M  represents  the  synchronization  mark, 
S  represents  a  sequence  bit,  F  represents  a  fill  bit,  the  dash 
represents  68  other  data  octets,  and  an  D  represents  a  data  bit. 

In  the  line  below  the  normal  values  have  been  filled  in  for  the  length, 
the  command,  the  synchronization  mark  and  fill  bits. 

OlOOllOOOOlllOOllOlllOOlOllOOOOllllOOlOODDDDDDSSDDDDDDDD-DOOOOOOO 
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3.  Character  Representation  and  Code  Identification 

The  standard  7-bit  character  representation,  with  b,  the  high-order  bit  and  bj  the  low-order  bit, 
is  shown  below: 

EXAMPLE:  The  bit  representation  for  the  character  “K,”  positioned  in  column  4,  row  1 1,  is 

^7  ^6  ^5  ^4  ^3  ^  ^1 

10  0  10  11 

The  code  table  position  for  the  character  “K”  may  also  be  represented  by  the  notation  “column  4, 
row  11”  or  alternatively  as  “4/1 1.” The  decimal  equivalent  of  the  binary  number  formed  by  bits  b^,  bj, 
and  bj,  collectively,  forms  the  column  number,  and  the  decimal  equivalent  of  the  binary  number 
formed  by  bits  b^,  bj,  bj,  and  bp  collectively,  forms  the  row  number. 

The  standard  code  may  be  identified  by  the  use  of  the  notation  ASCII  or  USASCII. 

The  notation  ASCII  (pronounced  as'-key)  or  USASCII  (pronounced  you-sas'-key)  should  or¬ 
dinarily  be  taken  to  mean  the  code  prescribed  by  the  latest  issue  of  the  standard.  To  explicitly  desig¬ 
nate  a  particular  (perhaps  prior)  issue,  the  last  two  digits  of  the  year  of  issue  may  be  appended,  as, 
“ASCII  63"  or  “USASCII  63”. 


4.  Legend 


4.1  Control  Characters 

NUL  NuU 

DLE 

Data  Link  Escape  (CC) 

SOH 

Start  of  Heading  (CC) 

DCl 

Device  Control  1 

SIX 

Start  of  Text  (CC) 

OC2 

Device  Control  2 

ETX 

End  of  Text  (CC) 

DC3 

Device  Control  3 

EOT 

End  of  Transmission  (CC) 

DC4 

Device  Control  4  (Stop) 

ENQ 

Enquiry  (CC) 

NAK 

Negative  Acknowledge  (CC) 

ACK 

Acknowledge  (CC) 

SYN 

Synchronous  Idle  (CC) 

BEL 

Bell  (audible  or  attention  signal) 

ETB 

End  of  Transmission  Block  (CC) 

BS 

Backspace  (FE) 

CAN 

Cancel 

HT 

Horizontal  Tabulation  ( punched  card  skip )  ( FE) 

EM 

End  of  Medium 

LF 

Line  Feed  (FC) 

SUB 

Substitute 

VT 

Vertical  Tabulation  (FE) 

ESC 

Escape 

FF 

Form  Feed  (FE) 

FS 

File  Separator  (IS) 

CR 

Carriage  Return  (FE) 

GS 

Croup  Separator  (IS) 

SO 

Shift  Out 

RS 

Record  Separator (io» 

SI 

Shift  In 

US 

Unit  Separator  I  IS) 

DEL 

Delete* 

NOTE:  ICC)  Communkaiion  Control 
IFEI  Formal  EiTeciOi 
I  IS)  Information  Seoaraior 

'In  the  strict  lenac,  DEL  ia  not  a  control  <’Iiiracier.  ( See  3.2.1 
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4.2  Graphic  Characters 


Column/Row 

Symbol 

Name 

2/0 

SP 

Space  (Normally  Non-Printing} 

2/1 

j 

Exclamation  Point 

2/2 

II 

Quotation  Marks  (Diaeresis^} 

2/3 

n 

Number  Sign*'* 

2/4 

s 

Dollar  Sign 

2/5 

% 

Percent 

2/6 

& 

Ampersand 

2/7 

Apostrophe  (Closing  Single  Quotation  Mark;  Acute  Accent* 

2/8 

( 

Opening  Parenthesis 

2/9 

I 

Closing  Parenthesis 

2/10 

* 

Asterisk 

2/11 

+ 

Plus 

2/12 

1 

Comma  (Cedilla* ) 

2/13 

- 

Hyphen  (Minus} 

2/14 

• 

Period  (Decimal  Point} 

2/15 

/ 

Slant 

3/10 

r 

Colon 

3/11 

; 

Semicolon 

3/12 

< 

Less  Than 

3/13 

Equals 

3/14 

> 

Greater  Than 

3/15 

7 

Question  Mark 

4/0 

($ 

Commercial  At* 

5/11 

\ 

Opening  Bracket* 

5/12 

\ 

Reverse  Slant* 

5/13 

I 

Closing  Bracket* 

5/14 

A 

Circumflex*’* 

5/15 

- 

Underline 

6/0 

' 

Crave  Accent*  *  (Opening  Single  Quotation  Mark} 

7/11 

1 

f 

Opening  Brace* 

7/12 

1 

1 

Vertical  Line* 

7/13 

1 

Closing  Brace* 

7/14 

' 

Overline*  (Tilde*;  General  Accent*} 

'  he  uic  of  the  »ymbol»  in  2/2,  2/7,  2/1 2.  5/14,  6/0.  end  7/14  m  dU  rilicol  mark*  i»  dtKhbed  in  Api^ndii  A,  AS.2. 
'Theee  chareclen  ahould  noi  be  u»fd  in  inlernaiional  interchantc  » ithout  determininf  lhai  there  u  afrecment  b*> 
i«reen  aender  and  recipient.  (See  Appendii  B4.( 

*ln  application*  where  there  is  no  requirement  (or  the  lymboi  f ,  the  aymbd  Z  may  be  uacd  in  poaition  2/3. 
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The  ARPANET  provides  a  capability  for  geographically 
separated  computers  i  callai  Ho >t s .  to  communicate  with  each 
other  The  Host  computers  typically  differ  from  one  another  in 
type,  speed,  word  length,  operating  system,  etc.  Each  Host 
computer  is  connected  into  the  network  through  a  local  small 
computer,  called  an  Interface  Message  Processor  (IMP);  a  typical 
network  section  is  shown  in  Figure  1-1 .  The  complete  network  is 
formed  by  interconnecting  these  IMPs  through  wideband 
communication  lines  supplied  by  common  carriers.  Each  IMP  is 
then  programmed  to  store  and  forward  messages  to  the  neighboring 
IMPS  in  the  network.  During  a  typical  operation,  a  Host  passes  a 
message  to  its  IMP;  this  message  is  then  passed  from  IMP  to  IMP 
through  the  network  until  it  finally  arrives  at  the  destination 
IMP,  which  in  turn  passes  it  along  to  the  destination  Host. 

Several  models  of  IMPS  are  currently  in  existence.  All 
perform  the  basic  function  of  a  store  and  forward  mode,  but  they 
have  different  physical  configurations  and  data  handling  rates. 
The  Model  516  (see  Figure  1-2)  is  the  original  IMP.  The  Model 
316  (see  Figure  1-3)  is  a  less  expensive  and  somewhat  slower 
version  of  the  original  IMP.  The  316  Terminal  IMP  or  TIP  (see 
Figure  1-4)  is  a  Model  316  IMP  mounted  in  a  double  hi-boy  rack 
along  with  a  BBN  Multi-Line  Controller  (MLC)  The  316  Terminal 


Model  516  IMP,  Modem  Cabinet,  and  IMP  Teletype 
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This  document  contains  the  _ sped ficatiionji.  .^,.for 

interconnecting  a  Host  and  an  IMP  and  may  be  subject  to  change. 
The  interconnection  of  a  Host  and  an  IMP  is  a  Joint  effort  that 
requires  the  Host  personnel  to  provide  interfacing  hardware  and 
software.  Although  we  have  tried  to  provide  sufficient 
information  to  assist  the  Host  personnel  in  the  design  of  the 
interface,  problems  and  questions  that  we  have  not  anticipated 
will  undoubtedly  arise.  These  questions  should  be  addressed  to: 

Network  Control  Center 
Bolt  Beranek  and  Newman  Inc. 

10  Moulton  Street 
Cambridge,  Massachusetts  02138 

Ue  strongly  recommend  that  the  pe'^sonnel  responsible  for  the 
design  of  the  Host  hardware  and  software  interfaces  visit  in 
Cambridge  with  the  technical  staff  of  Bolt  Beranek  and  Newman 
Inc.  for  a  thorough  review  of  the  designs  prior  to 
implementation.  We  feel  that  this  procedure  will  help  to 
minimize  the  difficulties  that  will  be  encountered  in  connecting 
the  Host  and  the  IMP. 
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2.  GENERAL  REQUIREMENTS 

In  this  section,  we  describe  the  physical  configuration  of 
the  IMP,  the  space  and  power  requirements,  the  equipment 
necessary  to  interconnect  the  IMP  and  Host  and  the  facilities 
that  must  be  provided  by  the  IMP  site  to  assist  with  installation 
and  maintenance  of  the  IMP. 

2.1  Physical  Configuration 

As  shown  in  Figure  2-1,  four  pieces  of  equipment  are 
provided:  the  IMP  itself,  which  is  a  modified  Honeywell  H-516R, 
Honeywell  H-316,  BBN  Pluribus  computer  or  BBN  C/30  computer;  an 
ASR-33  Teletype  or  Infoton  Vistar;*  a  high-speed  paper  tape 
reader  (optional);  and  a  cabinet,  approximately  the  same  size  as 
the  Model  516R,  that  contains  mourns  connecting  the  IMP  to  the 
communication  lines.  The  telephone  company  will  supply  modems 
only  for  the  communication  lines  actually  installed.  In 
addition,  the  telephone  company  usually  supplies  auxiliary 
equipment  that  may  vary  from  site  to  site  and  need  not  be  located 
near  the  modem  cabinet  or  the  IMP. 

A  Host  is  connected  to  an  IMP  by  a  Host  cable.**  The 
particular  cabling  scheme  is  determined  by  the  distance  between 

■*The  Vistar  is  a  keyboard/display  type  terminal  used  with  the 
Pluribus.  It  performs  the  same  functions  as  the  ASR-33  Teletype. 
**The  cables  in  Figure  2-1  are  drawn  only  schematically  rather 
than  in  their  actual  positions. 
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the  Host  and  the  IMP.  A  local  Host  (one  close  to  the  IMP)  is 
connected  by  a  30-foot  cable*  that  is  supplied  with  the  IMP. 
This  cable  connects  a  standard  Host/IMP  interface  unit  built  into 
the  IMP  to  a  special  interface  provided  by  the  Host. 

A  distant  Host  may  be  located  up  to  2000  feet  from  the  IMP, 
but  an  addition  to  the  standard  Host/IMP  interface  is  required  to 
modify  the  line-driving  scheme.  The  Host  personnel  must  design  a 
special  interface  that  is  compatible  and  must  supply  the 
connecting  cable  as  specified  in  Section  4.5.2.  Since  additional 
IMP  hardware  must  be  supplied,  the  decision  to  connect  a  distant 
Host  must  be  made  known  well  in  advance.  A  distant  Host  will 
usually  be  connected  to  an  IMP  which  has  one  or  more  local  Hosts. 

A  very  distant  Host  may  be  located  even  farther  from  the 
IMP,  using  an  entirely  different  interface  arrangement  which  is 
described  in  Appendix  F.  Basically,  the  very  distant  Host 
interface  is  designed  for  use  over  communication  circuits  with 
speeds  up  to  230.4  kilobits/second  and  up  to  tens  (perhaps 
hundreds)  of  miles  long.  The  communication  protocol  used  with 
this  interface  includes  a  24-bit  cyclic  redundancy  check  and  a 
positive  acknowledgment  scheme. 


*The  length  of  this  cable  is  limited  by  the  characteristics  of 
the  cable  drivers  in  the  IMP. 
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A  separate  30-foot  cable  is  provided  with  the  IMP  for  the 
connection  to  each  modem.  In  addition,  cables  are  provided  for 
connecting  the  terminal  (Teletype  or  Vistar)  and  paper  tape 
reader  (if  supplied)  to  the  IMP.  For  the  H-516R  and  H-316  IMPs, 
cables  exit  from  the  IMP  through  the  bottom  of  the  rear  panel. 
Cables  will  exit  from  the  modem  unit  through  the  bottom  of  the 
modem  cabinet;  if  a  site  does  not  have  a  false  floor,  other  modem 
cable  arrangements  are  easily  provided.  Cables  are  connected  to 
the  Pluribus  IMP  via  a  fantail  panel  located  at  the  rear  of  the 
machine . 

Figures  2-2,  2-3 i  2-4,  and  2-5  depict  the  floor  space 
requirements  for  the  516  IMP,  the  316  IMP,  the  (maximum  size)  316 
TIP,  and  the  (minimum  size)  Pluribus  IMP  respectively.  Some 
configurations  of  the  316  TIP  may  only  require  the  same  floor 
space  as  a  316  IMP,  and  some  Pluribus  IMPs  may  require  several 
racks  aide  by  aide;  the  Network  Control  Center  can  furnish 
details  for  each  installation. 

With  the  Honeywell  machines,  provision  should  be  made  to 
place  the  ASR-33  Teletype  close  to  the  IMP.  The  ASR-33  occupies 
approximately  2*  x  2*  of  floor  apace.  (The  optional  paper  tape 
reader  must  be  placed  nearby  if  it  is  supplied.*  Its  dimensions 
are  11  X  11  X  23  inches  (WIDTH  x  HEIGHT  x  DEPTH).  A  convenient 

•to  determine  whether  a  paper  tape  reader  will  be  supplied,  a 
site  may  contact  the  Network  Control  Center. 
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^  HINGED  DOOR  USED  ON 
EARLY  MODELS  ONLY: 
REMOVABLE  BACK  PANEL 


USED  ON  LATER  MODELS 


PULL-OUT 

LOGIC 

DRAWER 


CONTROL 

PANEL 


LEAVE  MINIMUM  OF 
12"  FOR  ACCESS 


TOP  VIEW 

Figura  2-3  Minimum  Floor  Area  Required  for  316  IMP 
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location  is  the  top  of  the  IMP  cabinet,  if  overhead  space 
permits.)  With  the  Pluribus  machine,  table  space  should  be 
provided  nearby  for  the  Infoton  Vistar.  Its  dimensions  are  20  x 
13  X  24  inches.  (Again,  the  optional  paper  tape  reader  must  be 
placed  nearby  if  it  is  supplied.*  Its  dimensions  are  20  x  8  x  22 
inches.  It  can  be  located  on  top  of  the  IMP  cabinet  if  overhead 
space  permits.) 

A  small  lockable  cabinet  is  needed  on  the  Host  premises  for 
the  storage  of  IMP*related  materials  (e.g.,  manuals,  test  tapes, 
scope,  tool  box,  etc.).  Finally,  a  telephone  should  be  located 
within  reach  of  both  the  terminal  and  the  operating  panel  of  the 
IMP  for  use  during  diagnosis  and  debugging. 

The  locations  of  the  IMP,  modem  cabinet,  paper  tape  reader, 
and  Teletype  are  to  be  selected  by  the  Host  personnel.  These 
pieces  of  equipment  should  be  placed  within  approximately  eight 
feet  of  one  another.  A  minimum  of  thirty  square  feet  of  floor 
space  is  required  for  the  equipment,  and  additional  space  must  be 
available  for  accessing  the  machine  during  maintenance  and 
debugging.  Access  to  the  Model  516  IMP  is  via  a  full*length 
front  door,  which  is  hinged  on  the  left  side.  Access  to  the  316 
IMPS  is  via  drawers  which  slide  to  the  front.  Access  to  the 
Pluribus  IMP  is  via  full-length  rear  doors  and  removable  front 

*To  determine  whether  a  paper  tape  reader  will  be  supplied,  a 
site  may  contact  the  Network  Control  Center. 
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panels.  Access  to  the  modem  cabinet  is  via  a  removable  front 
panel . 

In  addition  to  the  modem  cabinet,  the  telephone  company  may 
provide  another  cabinet  to  contain  the  auxiliary  equipment.  It 
is  recommended  that  this  auxiliary  equipment  be  placed  in  an 
inconspicuous  location  on  the  Host  premises,  such  as  in  a 
telephone  company  equipment  room,  since  immediate  access  to  this 
equipment  is  not  necessary. 

2.2  Description  of  Equipment 

External  dimensions,  approximate  weights,  and  power 
requirements  of  the  various  IMP  models  are  given  in  Table  2-1 . 
The  paper  tape  reader  weighs  approximately  25  pounds,  the  ASR-33 
Teletype  weighs  approximately  56  pounds,  and  the  Infoton  Vistar 
weighs  approximately  55  pounds. 

The  Model  516  IMP  is  a  ruggedized  unit  with  EMI  protection. 
All  IMPS  will  operate  in  an  ambient  environment  from  17  to  30 
degrees  centigrade  and  up  to  951  humidity.  However,  these 
features  have  been  included  for  reliability  and,  in  general,  an 
environment  suitable  for  most  digital  computing  equipment  should 
be  provided;  i.e.,  air-conditioned  and  free  from  excessive  dust 
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Model 

_ _ Size _ (Inches) _ 

Weight 

Obs) 

Power 

(watts) 

Hel qht 

Width 

Depth 

516R  IMP 

74 

24 

28 

990 

2100 

316  IMP 

73 

26 

28 

525 

750 

316  TIP 

73 

52 

28 

920 

2200 

expansion  cabinet 

39 

25 

28 

100 

0 

>1ur1bus  IMP 
(per  reck) 

68 

22 

26 

550 

3000 

(approx) 

Table  2-1 

The  power  requirements  for  the  Honeywell  IMP  equipment  are 

as  follows: 

a)  115  VAC  ±  10S;  60  Hi  ±  5S,  single  phase.  The  line  cord 
is  15  ft.  long  and  contains  3‘*wire  cable  terminated  by  a 
30-affip  Hubbell  3331G  (NEMA  L5-30P)  twistlock  connector  (for 
wiring  convention,  see  Appendix  G) . 

b)  High-speed  reader  (optional);  115  VAC  t  101;  60  Hz, 

single-phase  at  125  watts.  (The  line  must  withstand  10-amp 
surges  at  125  VAC.)  The  line  cord  is  6  ft.  long  and  is 
terminated  in  a  standard  3*wire  grounded  plug. 

c)  ASR-33:  115  VAC  i  101;  60  Hz  ♦  0.45  Hz.  single  phase  at  230 

watts.  The  line  cord  is  8ft.  long  and  is  terminated  in  a 

standard  3-wire  grounded  plug. 
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Power  for  the  Pluribua  equipm<^nt  is  supplied  via  one  3-phase 
208/110  volt  wye  60  Hz  connection  per  rack.  Each  power  cord  is 
20  feet  long  and  is  terminated  by  a  Hubbell  2811  (NEHA  L21-30P} 
twistlock  connector.  Each  circuit  must  supply  30  amps  per  leg. 
Sufficient  convenience  outlets  for  debugging  equipment,  the 
Infoton  Vistar,  and  paper  tape  reader  are  provided  cr.  the 
Pluribus  itself. 


The  Host  must  provide  an  appropriate  power  receptacle 
(located  within  15  feet)  for  the  IHP  power  plug  and  it  is 
recommended  that  a  separate  fuse  or  circuit  breaker  be  provided 
on  the  IMP'S  power  line.  (The  Honeywell  IMP  normally  draws  about 
20  amps,  but  the  line  must  be  capable  of  supplying  up  to  30 
amps.)  The  IMP'S  chassis  is  connected  to  the  ground  (third)  lead 
of  the  power  plug,  which  is  completely  isolated  from  the  signal 
return  (i.e.,  "signal  ground").  If  at  all  feasible,  the  power  to 
the  IMP  should  be  provided  from  the  same  transformer  that 
delivers  power  to  the  Host  in  order  to  insure  a  common  ground. 
For  Honeywell  equipment,  three  115-VAC  wall  sockets  (located 
within  5  feet  of  the  IMP)  are  required  to  power  the  Teletype, 
paper  tape  reader,  and  an  IMP  debugging  oscilloscope  used  during 
installation  and  maintenance.  The  for  these  sockets  should 

be  fused  for  20  amps  and  should  be  powered  from  the  same 
transformer  as  the  IMP,  if  feasible. 
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The  modem  cabinet  dimensions  are  88-1/8"  x  28"  x  28";  it 
weighs  up  to  750  lbs  and  requires  up  to  15  amps  of  standard  115 
VAC  power.  The  modem  operates  in  an  ambient  environment  of  40 
degrees  to  120  degrees  Fahrenheit  and  up  to  95X  humidity.  The 
Host  must  provide  power  for  the  modem  from  the  same  transformer 
that  delivers  power  to  the  IMP.  A  standard  3-connector 
non-locking,  non-twist  plug  is  normally  provided  with  the  modem. 
The  telephone  company  also  recommends  that  a  separate  fuse  or 
circuit  breaker  be  provided  on  the  power  line  to  the  modem.  (The 
auxiliary  equipment  is  a  non-standard  item  that  will  vary  from 
site  to  site;  the  size  is  generally  no  larger  than  the  size  of 
the  modem  cabinet  and  may  be  as  small  as  a  2*  x  3*  wall  mounting. 
A  separate  power  outlet  will  also  be  needed  for  this  equipment.) 

In  all,  the  Honeywell  equipment  requires  six  receptacles, 
and  Pluribus  Uiachines  require  on**  receptacle  per  rack  plus  one 
for  the  modem  cabinet.  The  site  should  plan  to  provide  the  power 
necessary  for  the  phone  company  equipment  after  preliminary 
discussions  with  the  local  telephone  company  representatives  and 
before  the  circuit  installation  date. 

2.3  Interfacing 

The  Host/IHP  interface  is  subdivided  into  two  separate 
units,  as  Illustrated  in  Figure  2-6. 
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SPECIAL 
HOST/ IMP 
INTERFACE 


STANDARD 
HOST/  IMP 
INTERFACE 


Figure  2-6  Host/IMP  Interface 


The  right-hand  (standard)  unit  is  built  into  the  IMP  and 
contains  logic  that  is  standard  for  all  Kost/IHP  interfaces.  The 
left-hand  unit  contains  the  special  equipment  for  innerfacing 
directly  to  the  particular  Host.  An  addition  to  the  standard 
Host/IMP  interface  is  required  for  a  distant  Host.  Standard 
signals  pass  on  the  host  cable  between  these  two  halves;  all 
special  logic  and  signal  adjustments  (which  vary  from  Host  to 


own  special  unit  to  mate  to  the  standard  Host/IMP  Interface  unit . 
The  logical  operation  of  this  unit  will  be  the  same,  regardless 
of  whether  a  Host  Is  local  or  distant;  however,  a  different 
electrical  signaling  scheme  Is  required  to  handle  a  distant  Host. 
A  detailed  description  of  the  requirements  for  the  special  unit 
Is  given  In  Section  4.  The  very  distant  Host  Interface  follows 
the  same  general  philosophy  of  a  standard  Interface  unit  at  the 
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3.  SYSTEM  OPERATION 


3.1  Messages  and  Message-ids 


Hosts  communicate  with  each  other  via  regular  messages.  A 


regular  message  may  vary  in  length  from  96  up  to  8159  bits,  the 


first  96  of  which  are  control  bits  called  the  leader.  The  leader 


is  also  used  for  sending  control  messages  between  the  Host  and 


its  IMP,  in  which  case  only  the  first  80  bits  are  used.  The 


remainder  of  the  message  is  the  data ,  or  the  text. 


For  each  regular  message,  the  Host  specifies  a  destination , 


consisting  of  IMP,  Host,  and  handling  type.  These  three 


parameters  uniquely  specify  a  connection  between  source  and 


destination  Hosts.  The  handling  type  gives  the  connection 


specific  characteristics,  such  as  priority  or  non-priority 


transmission  (see  below).  Additional  leader  space  h'^s  been 


reserved  for  a  fourth  parameter,  to  be  used  in  future 


inter-network  addressing.  For  each  connection,  messages  are 


delivered  to  the  destination  in  the  same  order  that  they  were 


transmitted  by  the  source. 


For  each  regular  message,  the  Host  also  specifies  a  12-bit 


identifier,  the  message- id .*  The  message- id,  together  with  the 


destination  of  the  message,  is  used  as  the  "name"  of  the  message. 


•Until  mid-197i  the  first  eight  bits  of  the  message-id  field  were 
called  the  "link". 


aw 
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The  IMP  will  use  this  name  to  inform  the  Host  of  the  disposition 
of  the  message.  Therefore,  if  the  Host  refrains  from  re-using  a 
particular  message-id  value  (to  a  given  destination)  until  the 
IMP  has  responded  about  that  message- id,  messages  will  remain 
uniquely  identified  and  the  Host  can  retransmit  them  in  the  event 
of  a  failure  within  the  network. 

After  receiving  a  regular  message  from  a  Host  connected  to 
it,  an  IMP  breaks  the  message  into  several  packets  (currently  the 
maximum  data  bits/packet  is  1008)  an  i  passes  these  through  the 
network  in  the  direction  of  the  destination.  Eventually,  when 
all  packets  arrive  at  the  destination,  they  are  reassembled  to 
form  the  original  message  and  passed  to  the  destination  Host. 
The  destination  IMP  returns  a  positive  acknowledgment  for  receipt 
of  the  message  to  the  source  IMP,  which  in  turn  passes  this 
acknowledgment  to  the  source  Host.  This  acknowledgment  is  called 
a  Ready  for  Next  Message  (RFNM)  and  identifies  the  message  being 
acknowledged  by  name.  In  some  relatively  rare  cases,  however, 
the  message  may  be  lost  in  the  network  due  to  an  IMP  failure;  in 
such  cases  an  Incomplete  Transmission  message  will  be  returned  to 
the  source  Host  instead  of  a  RFNM.  Again,  in  this  case,  the 
message  which  was  incompletely  transmitted  is  identified  by  name. 

If  a  response  from  the  destination  IMP  (either  RFNM  or 
Incomplete  Transmission)  is  itself  lost  in  the  network,  this 
condition  will  be  detected  by  the  source  IMP,  which  will 
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automatically  inquire  of  the  destination  IMP  whether  the  original 
message  was  correctly  transmitted  or  not,  and  repeat  the  inquiry 
until  a  response  is  received  from  the  destination  IMP.  This 
inquiry  mechanism  is  timeout-driven,  and  each  timeout  period  may 


be  as  little  as  30  or  as  much  as  45  seconds  in  length. 


When  a  message  arrives  at  its  destination,  the  leader  is 


modified  to  indicate  the  source  Host,  but  the  message-id  field  is 


passed  through  unchanged.  Thus,  in  addition  to  providing  message 


identification  between  a  Host  and  its  local  IMP,  the  message-id 


can  provide  a  means  for  Hosts  to  identify  messages  between 


themselves.  For  example,  the  message-id  can  be  used  for 


multiplexing  several  independent  data  streams,  or  for  keeping 


track  of  the  portions  of  a  single  data  stream  being  sent  "in 


parallel"  through  the  network. 


If  the  priority  bit  of  the  handling  type  is  set,  the  message 


will  be  expedited  through  the  network  by  being  placed  at  the 


front  of  the  various  transmission  queues  it  will  encounter  along 


the  way.  This  can  be  useful  for  transactions  requiring  minimal 


delay  (e.g.,  remote  echoing  or  the  exchange  of  control 


information)  but  should  be  used  Judiciously,  since  the  more  it  is 


used  the  less  effect  each  further  use  will  have. 


In  order  to  prevent  various  types  of  dei^dlocks  within  the 


network,  a  source  IMP  must  guarantee  that  the  destination  IMP 
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will  have  enough  storage  to  accept  the  message  it  is  about  to 
send.  This  is  done  by  preceding  each  message  with  a  short 
"request  for  buffer  space"  message.  When  the  destination  has 
enough  buffer  space  to  receive  another  message,  it  returns  an 
"allocation"  to  the  source  IMP,  which  can  then  send  the  message 
it  has  been  holding. 

There  art  several  situations  in  which  an  IMP  may  temporarily 
block*  the  transmission  of  a  message  from  the  source  Host  to  the 
source  IMP.  In  general,  any  such  blockage  will  last  for  only  a 
few  milliseconds,  but  in  some  cases  the  blockage  may  be 
indefinite.  In  at  least  one  such  case  the  IMP  will  be  unable  to 
accept  the  remainder  of  a  message  from  its  Host  until  it  frees 
buffer  space  by  delivering  some  message  to  the  Host  (it  is  for 
this  reason  that  half-duplex  Host-IMP  interfaces  are  prohibited). 
In  all  such  case»,  in  order  to  prevent  permanently  hanging  up 
transmission  between  the  Host  and  the  IMP,  the  source  IMP  will 
discard  the  message  after  a  wait  of  about  fifteen  seconds  and 
return  a  type  9  (sub- type  4)  message  (see  Section  3*4)  to  the 
Host,  thus  limiting  the  length  of  time  that  the  interface  will  be 
blocked.  Similarly,  once  a  Host  has  begun  to  send  the  IMP  a 
message,  it  must  be  prepared  to  deliver  the  entirety  of  that 
message  to  the  IMP  promptly.  In  particular,  the  IMP  will  discard 
any  message  that  is  not  completely  received  from  its  Host  in 

"&y  failing  to  provide  Ready-for-Next-Bit ,  see  Section  4.1. 
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fifteen  seconds  and  return  a  type  9  (sub-type  2)  message  to  the 
Host  (see  Section  3.^). 

One  situation  under  which  interface  blocking  will  occur  is 
when  the  source  IMP  must  wait  to  receive  an  allocation  from  the 
destination  IMP.  Since  a  Host  cannot  send  other  messages  into 
the  network  while  its  interface  is  blocked,  it  is  desirable  to 
expedite  the  "allocation"  mechanism,  and  this  is  done  in  two 
different  ways  depending  upon  message  length.  For  one-packet 
messages,  the  message  itself  is  sent  as  its  own  request.  Thus, 
if  space  is  available,  the  message  is  immediately  accepted  and  no 
additional  delay  is  incurred.  For  multi-packet  messages,  when 
the  destination  IMP  is  about  to  return  a  RFNM  it  reserves  storage 
in  anticipation  of  the  source  Host's  next  message,  and  returns 
the  allocation  along  with  the  acknowledgment.  Thus,  when  the 
source  IMP  eventually  sends  its  Host  the  RFNM,  it  is  also 
implicitly  informing  it  of  the  allocation  now  being  available.* 
If  the  Host  responds  promptly  with  another  message  on  that  same 
connection  (message- id  is  irrelevant) ,  the  message  can  be 
forwarded  immediately,  avoiding  any  set-up  delay  waiting  for  an 
allocation.  If  this  allocation  remains  unused  for  about  125  ms, 
it  is  returned,  unused,  to  the  destination.  Note  thct  this 

"In  some  (rare)  cases  the  destination  is  unable  to  reserve 
storage  immediately,  and  returns  a  RFNH  without  the  reservation. 
Currently,  the  destination  waits  1/2  second,  attempting  to 
reserve  storage,  before  returning  the  RFNM  without  an 
accompanying  reservation. 
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the  new  connection,  and  the  destination  must  reply  with 
a  confirmation  that  it  has  also  acquired  the  table 
space.  This  action  may  result  in  a  small  additional 
delay  before  Host  communication  can  begin.  The  pool 
will  be  sufficiently  large  to  seldom  interfere  with  a 
pair  of  Hosts  wishing  to  communicate.  In  no  case  will 
Hosts  be  prevented  from  communicating  because  of  lack  of 
these  reso«.’rces.  In  the  event  that  the  Hosts  on  an  IMP 
desire  to  simultaneously  communicate  with  so  many  other 
Hosts  that  the  pool  would  be  exhausted,  the  space  in  the 
pool  is  quickly  multiplexed  in  time  among  all  the 
desired  Host/Host  conversations  so  that  none  is  stopped 
although  all  are  possibly  slowed. 

Section  3.7  describes  an  optional  mechanism  available  to 
Hosts  that  wish  to  keep  interface  blocking  to  a  minimum. 

3.2  Establishing  and  Breaking  Host/IMP  Communications 

Each  IMP  and  Host  interface  has  its  own  hardware  Ready 
indicator.  The  Ready  indicator  in  the  standard  Host/IMP 
interface  will  be  on  whenever  the  IMP  is  powered  on  and  both  the 
IMP  program  anv,  the  IMP  hardware  are  determined  to  be  working 
properly.  The  Ready  indicator  in  the  special  Host  interface 
should  be  on  whenever  the  Host  is  powered  on,  the  hardware  is 
working  properly,  and  the  Host's  Network  Control  Program  (NCP)  is 
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running.  If  the  Host  temporarily  neglects  communications  with 
the  IMP,  the  Host's  hardware  Ready  indicator  should  not  go  off. 
An  off  indication  should  mean  only  that  something  is  broken  or 
that  communications  have  been  willfully  cut  off  for  an  extended 
period  (cable  removed,  power  shut  off,  routine  maintenance 
programs  running,  batch  processing  with  no  network  program 
running  etc .) . 

In  addition  to  the  Ready  indicator,  the  standard  interface 
has  a  flip-flop,  called  the  Error  flip-flop,  which  remembers  a 
not-ready  indication  from  the  Host  or  the  IMP.  This  flip-flop  is 
used  to  detect  any  momentary  off  condition  on  either  the  Host's 
ready  line  or  the  IMP'S  ready  line.  The  flip-flop  is  cleared  by 
the  IMP  program  each  time  the  program  enables  (i.e.,  prepares  to 
receive)  a  new  input  from  the  Host  and  is  tested  by  the  program 
when  the  input  is  completed.  The  'nput  is  discarded  if  the  Error 
flip-flop  is  turned  on. 

To  establish  communication,  a  Host  should  simply  send  its 
message  to  the  IMP.  The  operational  IMP  program  will  process  any 
message  transmitted  from  the  Host.  The  Host  must  always  send  at 
least  three  NOP  messages*  to  the  IMP  wheneve.  either  the  Host  or 
the  IMP  Ready  line  is  turned  on,  for  the  reasons  described  below. 
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One  reason  is  that  the  Host-to-IMP  NOP  message  contains 
information  as  to  how  much  leader  padding  is  to  be  contained  in 
regular  Host-to-IMP  and  IMP-to-Host  messages.  Also,  until 
old-style  leader  formats  (Appendix  A)  are  no  longer  used,  this 
NOP  informs  the  IMP  of  the  style  of  leader  the  Host  is  using. 

Another  reason  is  that  in  general,  when  the  Host  Ready 
indicator  goes  off,  the  IMP  program  will  be  either  receiving  or 
waiting  (in  an  input  command)  to  receive  a  message  from  the  Host. 
Upon  resumption  of  transmission  by  the  Host,  the  IMP  will 
unwittingly  append  the  new  information  to  the  unfinished  input. 
Upon  completion  of  the  message,  the  IMP  program  will  note  that 
the  Error  flip-flop  is  on  and  thus  discard  the  entire  message. 
To  guarantee  that  a  useful  new  message  is  not  thereby  discarded, 
the  first  message  sent  by  the  Host  after  its  Ready  indicator 
comes  on  should  be  a  discardable  NOP  message.  The  special 
interface  should  have  a  similar  Error  flip-flop,  and  the  Host's 
Network  Control  Program  should  be  designed  to  use  this  flip-flop 
in  a  similar  manner. 

When  the  Host  Ready  indicstcr  ccess  on,  it  will  generally 
alternate  a  few  times  between  on  and  off  (due  to  relay  contact 
bounce  --  see  Section  M.4)  before  setting  solidly  on.  The  Host 
should  delay  an  appropriate  period  to  permit  its  ready  indicator 
to  stabilize  before  starting  output  or  preparing  for  input. 
Failure  to  do  so  may  cause  incorrect  data  to  be  taken  from  or 
sent  to  the  IMP. 
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A  Host  may  go  down,  thus  halting  network  traffic  to  itself 
from  other  Hosts,  in  either  of  two  ways:  by  turning  off  its 
ready  indicator  (hard  down),  or  by  failing  to  accept  messages 
from  the  IMP  (tardy  down).  In  either  case,  the  IMP  will  mark  the 
Host  as  dead  and  see  to  it  that  any  attempt  to  communicate  with 
the  Host  results  in  a  Destination  Dead  response. 

The  IMP  program  tests  the  Host  Ready  indicator  (not  the 
Error  flip-flop)  every  half-second.  If  the  program  ever  finds 
this  ready  indicator  off,  the  Host  will  be  marked  dead  (hard 
down)  and  the  IMP  will  discard  old  messages  for  transmission  to 
the  Host  and  will  set  up  3  NOP  messages  followed  by  a  type  10 
message  for  transmission  to  the  Host.  Both  the  IMP  and  the  Host 
must  discard  any  NOP  messages  that  are  recognized  as  such.  (A 
NOP  message  that  is  appended  to  an  unfinished  message  may  not  be 
recognized,  but  it  will  be  discarded  as  discussed  above.) 

The  IMP  follows  the  above  procedures  when  the  Host  Ready 
indicator  is  off  momentarily  or  for  an  extended  period.  The 
following  steps  are  taken  by  the  IMP  when  its  own  indicator  has 
gone  off. 

1.  The  Error  flip-flop  is  turned  on.  This  action  will 
cause  the  first  incoming  message  from  the  Host  to  be 
discarded . 
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2.  Old  messages  for  transmission  to  the  Host  are  discarded. 

3.  The  IMP  Ready  indicator  is  turned  on. 

4.  Sufficient  NOP  messages  are  placed  on  the  output  queue 
to  the  Host  to  cover  the  period  of  relay  bounce  and 
insure  correct  transmission  of  at  least  one  NOP. 

5.  A  Type  10  message  is  placed  on  the  output  queue  to  the 
Host. 

The  Host  should  employ  a  similar  procedure  whenever  its  own 
Ready  indicator  has  gone  off,  except  that  old  messages  for 
transmission  to  the  IMP  need  not  necessarily  be  discarded. 

In  order  to  not  tie  up  network  resources  for  an  inordinate 
amount  of  time,  Hosts  must  be  prepared  to  accept  messages  from 
the  network  promptly.  In  particular,  any  given  message  will  be 
discarded  if  it  resides  on  a  queue  to  the  Host  for  mere  than 
thirty  seconds.  (With  the  current  IMP  system,  this  requires  that 
the  Host  must  read  its  interface  at  the  rate  of  about  1 ,500 
bits/ second,  averaged  across  about  twenty  seconds.)  If  the  Host 
does  not  meet  this  constraint,  the  IMP  will: 

1.  Declare  the  Host  to  be  "tardy  down". 

2.  Discard  all  messages  pending  on  the  queues  to  the  Host. 
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3.  Momentarily  drop  its  ready  line  (thus  setting  the  error 
flip-flop).  This  is  done  because  a  component  failure  in 
the  interface  may  have  caused  the  handshaking  procedure 
(see  Section  4.2)  to  get  out  of  step)  which  would  have 
the  same  effect  as  the  Host  merely  being  tardy. 
"Flapping”  the  ready  line  insures  that  the  interfaces 
“sre  synchronized. 

4.  Place  some  N0P*s  and  a  type  10  message  on  the  queue  to 
the  Host. 

The  Host  will  be  declared  up  the  next  time  that  it  sends  a 
message  to  the  IMP  or  accepts  a  message  from  the  IMP.  The  Host 
must  send  at  least  three  NOP  messages  to  the  IMP  if  it  is  aware 
that  it  has  been  declared  tardy,  since  the  error  flip-flop  will 
cause  the  first  Host-to-IMP  message  to  be  discarded. 
(Alternatively,  the  Host  could  bring  down  its  own  ready  line;  the 
IMP  would  then  proceed  as  though  the  Host  were  in  a  hard  down, 
rather  than  continuing  to  treat  the  Host  as  though  it  were  in  a 
tardy  down.) 

If  the  Host  has  advance  warning  that  it  will  be  going  down, 
it  may  use  the  Host  Going  Down  message  (see  Section  3.3)  to 
inform  the  IMP  of  its  status  (i.e.,  the  reason  for  and  duration 
of  the  down).  Transmission  of  this  message  from  the  Host  to  the 
IMP  will  not  cause  the  IMP  to  declare  the  Host  down;  the  IMP 
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TYPE  0 

MES^A^ES  ONLY 


Figure  3-1  Host-to-IMP  Leader  Format 


Bits  1  -  4  Unassigned  - 
Must  be  zero. 


Bits  5-8  New  Format  Flag  - 


These  bits  are  always  set  to  the  value  15.  This  permits  the 
IMP  to  distinguish  between  new-style  and  old-style  (Appendix 
A)  leaders. 
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Bits  9-16  Destination  Network  - 

For  future  use,  these  bits  must  always  be  zero. 

Bits  17  -  20  Unassigned  - 
Must  be  zero. 

Bit  21  Trace  - 

If  equal  to  one,  the  message  is  designated  for  tracing  as  it 
proceeds  through  the  network  so  that  reports  of  this 
message’s  transit  through  the  network  may  be  sent  to  a  trace 
destination  (see  Section  5.5). 

Bits  22  -  24  Leader  Flags  - 

Bits  23  and  24  are  currently  unassigned  but  are  reserved  for 
future  network  use  and  must  be  zero.  Bit  22  is  available  as 
a  destination  Host  flag,  its  meaning,  if  any,  being  assigned 
by  that  Host.  The  only  Host  with  a  preassigned  meaning  is 
the  IMP  Teletype  Fake  Host.  If  the  bit  is  one,  the  message 
will  be  printed  on  the  Teletype  as  a  sequence  of  octal 
numbers,  each  representing  one  16-bit  IMP  word.  If  equal  to 
zero,  then  the  message  will  be  printed  as  a  sequence  of 
ASCII  characters.* 


*The  IMP'S  internal  ASCII  character  set  is  listed  in  Appendix  E. 
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Bits  25  -  32  Message  Type  - 

0.  Regular  Message  -  All  Host-to-Host  communication  occurs 

via  regular  messages.  Sub-types  (bits  77-80): 

0.  Standard,  Non-Refusable .  Interface  blocking  will 
occur  if  any  resource  needed  to  send  the  message  is 
not  immediately  available. 

1.  Ref usable*  Used  to  minimize  the  number  of  times  the 
interface  may  be  blocked.  If  any  resource  needed  to 
send  the  message  is  not  available,  the  message  is 
discarded,  and  the  Host  is  notified  via  a  type  11, 
12,  or  13  Host-to-IMP  control  message.  In  the  case 
of  a  type  12  (Refused,  will  notify)  response,  the 
IMP  is  committed  to  also  sending  a  type  14  (Ready) 
when  the  resource  does  become  available. 

2*  Get  Ready*  (see  Section  3*7).  Similar  to  Refusable 
(above),  except  only  the  leader,  rather  than  the 
full  message,  is  sent  in  to  the  IMP.  If  all 
necessary  resources  are  immediately  available,  the 
Host  is  notified  via  a  Type  14  message. 

3.  Uncontrolled  -  (see  Section  3*6).  The  IMP  will 
perform  no  message-control  functions  for  this  type 
of  message. 

4  -  15.  Unassigned. 

•The  non*  blocking  Host  interface  (see  Section  3.7)  is  not  yet 
implemented . 
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1 .  Error  Without  Message  Identification  -  The  Host  program 
detected  an  error  in  a  previous  IMP-to-Host  message  and 
had  to  assume  that  the  leader  was  garbled. 

Sub-types: 

0.  Host’s  error  flip-flop  was  set  during  transmission 
of  the  message. 

1.  Host  received  a  message  less  than  80  bits. 

2.  Host  received  a  message  of  an  unassigned  type  (3f 
15-255). 

3  -  15.  Unasslgned. 

2.  Host  Going  Down  -  It  is  assumed  that  as  the  time  for  the 
Host  to  (voluntarily)  go  down  approaches,  the  Host 
itself  will  send  warning  messages  to  its  network  users. 
Just  before  going  down,  the  Host  should  send  the 
Host-Going-Down  message  to  its  IMP.  The  Host  should 
then  (if  it  can)  continue  to  accept  messages  from  the 
IMP  for  a  period  of  5  or  10  seconds,  to  allow  messages 
already  in  the  network  to  reach  it.  The  IMP  will  store 
the  Host-Going-Down  message  and  return  it  to  any  source 
Host  along  with  Destination  (Host)  Dead  messages.  The 
IMP  will  try  to  preserve  this  message  over  IMP  reloads 
where  appropriate.  The  NCC  will  be  able  to  manually 
update  the  stored  copy  of  this  message  in  response  to  a 
phone  call  from  the  Host  site  in  the  event  the  Host  is 
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going  to  be  down  longer  than  it  said  or  if  it  did  not 
have  time  to  give  warning  before  going  down. 

Bits  65-76  (the  message-id  field)  of  the  Host-Going-Down 
message  give  the  time  of  the  Host's  coming  back  up, 
bit-coded  as  follows: 


Bits  65-67: 

Bits  68-72: 

Bits  73-76: 


the  day  of  the  week  the  Host  is  coming  back 
up.  Monday  is  day  0  and  Sunday  is  day  6. 
the  hour  of  the  day,  from  hour  0  to  hour 
23f  that  the  Host  is  coming  back  up. 
the  five  minute  interval,  from  0  to  1 1 ,  in 
the  hour  that  the  Host  is  coming  back  up. 


All  three  of  the  above  are  to  be  specified  in  Universal 
Time  (i.e.,  G.N.T.).  The  Host  may  indicate  that  it  will 
be  coming  back  up  more  than  a  week  away  by  setting  bits 
65-76  all  to  ones.  Setting  all  bits  65-75  to  one  and 
bit  76  to  zero  means  it  is  unknown  when  the  Host  is 
coming  back  up. 


Bits  77-80  (the  sub-type  field)  of  the  Host-Going-Down 
message  should  be  used  by  the  Host  to  specify  the  reason 
it  is  going  down.  These  bits  are  coded  (in  octal)  as 
follows: 


3-19 


5/78 


3-329 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1985 


Report  No.  1822 


Bolt  Beranek  and  Newman  Inc. 


Value  Meanlnf 


0-4  Reserved  for  IMP  use 

5  Scheduled  P.M. 

6  Scheduled  Hardware  Work 

7  Scheduled  Software  Work 

10  Emergency  Restart 

11  Power  Outage 

12  Software  Breakpoint 

13  Hardware  Failure 

14  Not  scheduled  up 

15  Unspecified  Reason 

16-17  Currently  Unused 


3 .  Unassigned . 

4.  2jOP  -  The  IMP  will  discard  this  message,  which  is 
intended  for  use  during  initialization  of  IMP/Host 
communication.  Bits  77-80  (the  sub-type  field)  contain 
the  number  of  16-blt  words  of  padding  (9  max.)  that  the 
Host  wishes  to  send  and  receive  on  type  0  messages. 
This  padding  occurs  immediately  after  the  leader 
(starting  at  bit  97)  and  is  provided  as  a  convenience 
for  Hosts  for  which  the  combined  Host/IMP  (IMP/Host)  and 
Host/Host  leaders  would  otherwise  not  be  an  integral 
number  of  memory  words.  A  simple  rule  for  the  Host  to 
follow  is  to  send  three  NOP  messages  whenever  the  Host 
or  the  IMP  has  been  down  either  voluntarily  or 
involuntarily. 

5 .  Unassigned . 

6.  Unassigned. 


7.  UnassiKned. 
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8.  Error  with  Message  Identification  -  The  Host  detected  an 
error  in  a  previous  IMP-to-Host  message  after  the  leader 
was  correctly  received;  e.g.,  the  message  was  too  long, 
or  the  IMP  Error  flip-flop  was  set  after  transmission  of 
the  first  packet  of  a  multiple  packet  message  but  before 
the  end  of  the  message.  A  message  of  this  type  will 
have  a  leader  whose  assigned  bits  are  identical  to  the 
assigned  bits  in  the  leader  of  the  message  in  error 
except  that  the  message  type  bits  will  be  changed  to 
have  value  8 . 

9-255.  (Jnassigned . 

Bits  33  -  40  Handling  Type  - 

This  field  is  bit-cCded  to  indicate  the  transmission 
characteristics  of  the  connection  desired  by  the  Host. 

Bit  33!  Priority  -  Most  messages  should  have  this  bit  set 
to  zero;  messages  with  this  bit  set  to  one  will  be 
treated  as  priority  messages  (see  Section  3*1)* 

Bits  34-37:  Currently  unassigned,  must  be  zero. 

Bits  38-40:  Maximum  Message  Size* 

The  maximum  size  (in  packets)  of  any  message  the 
Host  expects  to  send  on  the  connection  (Ipackets  = 
(Ibits  in  message  -  96)/1008).  This  number  is 

*Untii  this  is  implemented  by  the  IMP,  the  defai*lt  value  of  0 
should  be  used  by  the  Host. 
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expressed  as  (maximum  #  of  packets  -  1 )  and  ranges 
from  1  (2  packets  max)  to  7  (8  packets  max)  .  A 

value  of  zero  indicates  the  default  maximum  which 
Is  8  packets.  It  Is  to  the  advantage  of  the  Host 
to  specify  this  quantity  as  accurately  as  possible, 
since  it  enables  the  destination  IMP  to  make  the 
most  efficient  allocation  of  reassembly  space.  On 
the  other  hand,  messages  that  must  remain  in  strict 
sequence  must  all  have  the  same  handling  type. 
Multiple  connections  between  two  Hosts,  each  with  a 
different  maximum  message  size,  should  be  used  only 
when  there  are  large  differences  in  the  maxima  and 
strict  sequencing  is  not  required.  A  message  whose 
length  exceeds  the  specified  maximum  will  be 
discarded  and  type  9»  subtype  1  will  be  returned  to 
the  Host. 

Bits  Ml  -  48  Destination  Host  - 

Identify  the  particular  Host  at  an  IMP  site.  Host  numbers 
252-255  are  reserved  for  use  by  the  IMP’S  "fake"  Hosts  (see 
Section  5) • 

Bits  49  -  64  Destination  IMP  - 
Identify  the  IMP  site 
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Bits  65  -  76  Message-id  - 

Host-specified  identification  supplied  in  all  type  0  and  8 
messages.  Also  used  in  type  2  (Host-Going-Down)  message. 

Bits  77  -  80  Sub-type  - 

Used  by  message  types  0,  2,  4,  and  8. 

Bits  81  »  96  Message  Length  - 

This  field  is  used  for  type  0  messages  only  and  specifies 
the  length  (in  bits)  of  the  message,  exclusive  of  leader, 
leader  padding  and  hardware  padding.  The  only  use  that  the 
IMP  makes  of  this  field  is  the  Get  Ready  (Sub-type  2) 
message  where  it  is  used  to  determine  if  the  message  is 
single  or  multi-packet.  If  a  zero  length  is  given  in  a  Get 
Ready  message,  a  multi-packet  length  is  assumed. 

The  following  table  shows  which  non-constant  fields  are  used 
by  each  valid  message  type. 
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Bit  21  Trace  - 

If  equal  to  one,  source  designated  that  message  be  traced 
(see  Section  5.5).  Used  in  type  0  messages  only. 

Bits  22  -  24  Leader  Flags  - 

Bits  23  and  24  are  currently  unassigned  and  are  set  to  zero. 
Bit  22  may  be  assigned  a  meaning  by  the  destination  Host,  in 
which  case  it  is  used  by  the  source  Host  to  signal  some 
special  meaning,  e.g.  octal  printing  for  the  Teletype  Fake 
Host.  Used  in  type  0  messages  only. 

Bits  25  -  32  Message  type  - 

0.  Regular  Message  -  All  Host-to-Host  communication  occurs 
via  regular  messages.  The  subtype  field  is  the  same  as 
sent  in  the  Host-to-IMP  message;  in  particular  a 
sub-type  of  3  indicates  an  uncontrolled  message  (see 
Section  3.6). 

1 .  Error  in  Leader  -  the  IMP  detected  an  error  in  a 
previous  Host-to-IMP  message  and  had  to  assume  that  the 
leader  was  garbled. 

Sub-types: 

0.  IMP*s  Error  flip-flop  set  during  the  first  96 
bits  of  a  message  (see  Section  3.2). 

1.  IMP  received  a  message  of  less  than  80  bits  (32 
if  old  format) . 

2.  IMP  received  a  message  of  an  illegal  Type. 
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3.  IMP  received  a  message  of  the  opposite  leader 
style  than  it  was  expecting. 

2.  IMP  Going  Down  -  The  IMP  will  transmit  this  message  to 
its  Host  before  it  voluntarily  goes  down.  The  Host 
should  forward  the  information  in  the  message  to  its 
users  from  the  network  (and  to  its  own  users  of  the 
network) . 

Bits  65-80  of  the  message  are  coded  as  follows: 

Bits  65-66:  Why; 

0.  "last  warning"  or  "panic  restart":  The  IMP  is 
going  down  in  30  seconds. 

1.  Scheduled  hardware  PM 

2.  Scheduled  software  reload 

3.  Emergency  restart 

Bits  67-70:  How  Soon;  in  5  minute  increments  (zero 
implies  immediately) 

Bits  71-80:  For  How  Long;  in  5  minute  increments  (zei'o 
implies  immediately) 

3.  Unused. 

4.  NOP  -  The  Host  should  discard  this  message.  It  is  used 
during  initialization  of  IMP/Host  communication.  The 
Host  and  IMP  fields  will  contain  the  local  Host  and  IMP 
identification  numbers,  and  the  sub-type  field  will  be 
zero.  All  other  fields  are  unused. 
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rFNM  -  "Ready  for  Next  Message".  The  named  regular 
message  was  successfully  delivered  to  the  destination 
IMP,  and  the  destination  Host  accepted  it.  In  addition, 
if  the  named  message  is  longer  than  one  packet  (about 
1103  bits  including  leader)  space  may  be  reserved  at  the 
destination  IMP  for  another  transmission,  but  the  space 
reservation  will  remain  valid  for  only  a  short  time  (see 
Section  3.1).  The  subtype  field  will  be  0  if  the 
original  message  was  non-refusable ,  and  1  if  it  was 
refusable. 

Dead  Host  Status  -  Bits  65-76  (the  message-id  field) 
have  the  same  meanings  as  bits  65-76  in  the  Host-to-IMP 
type  2  (Host-Going-Down)  message  described  in  Section 
3.3.  Bits  77-80  (the  sub-type  field)  have  the  following 


meanings: 

Value 


Meaning 


Currently  Unused 


The  destination  Host  is  not  communicating 
with  the  network  —  it  took  its  ready-line 
down  without  saying  why. 

The  destination  Host  is  not  communicating 
with  the  network  --  the  Host  was  tardy  in 
taking  traffic  from  the  network  without 
saying  why. 
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3  The  destination  Host  does  not  exist  to  the 
knowledge  of  the  NCC. 

4  The  IMP  software  is  preventing  communication 
with  this  Host;  this  usually  indicates  IMP 
software  re-initialization  at  the 
destination. 


5 

The  destination 

Host 

is 

down 

for 

scheduled 

P.M. 

6 

The  destination 

Host 

is 

down 

for 

scheduled 

hardware  work. 

7 

The  destination 

Host 

is 

down 

for 

scheduled 

software  work. 

8 

The  destination 

Host 

is 

down 

for 

emergency 

restart. 

9 

The  destination 

Host 

is 

down  because  of  power 

outage. 

10 

The  destination 

Host 

is 

stopped 

I  at 

a  software 

breakpoint . 

11 

The  destination 

Host 

is 

down 

because  of  a 

hardware  failure. 

12  The  destination  Host  is  not  scheduled  to  be 

up. 

13-14  Currently  Unused. 

15  The  destination  Host  is  in  the  process  of 

coming  up. 
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When  the  value  of  the  sub-type  field  is  1,  2,  3»  o'" 


15,  the  message-id  field  will  have  the  "unknown" 


indication. 


Bit  33  In  this  message  will  always  be  set  to  zero  and 


Hosts  receiving  this  message  should  discard  (without 


reporting  an  error)  type  6  messages  with  bit  33  set  to 


1.  This  will  allow  the  later  addition  of  similar  status 


information  on  dead  destination  IMPs. 


The  Dead  Host  status  message  will  be  returned  to  the 


source  Host  shortly  (immediately,  if  possible)  after 


each  Destination  Host  Dead  (type  7,  subtype  1)  message. 


The  destination  Host  Dead  message  applies  to  a  specific 


named  message,  although  the  information  contained  in  the 


Destination  Host  Dead  message  should  probably  be 


reported  to  all  users  connected  to  the  dead  Host.  The 


Dead  Host  Status  message  does  not  apply  to  a  specific 


named  message  and  all  users  connected  to  the  dead  Host 


should  be  notified  of  the  information  contained  in  the 


Dead  Host  Status  message. 


Destination  Host  or  IMP  Dead  (or  unknown)  -  This 


message  is  sent  in  response  to  a  message  for  a 


destination  which  the  IMP  cannot  reach.  The  message  to 


the  "dead"  destination  is  discarded. 
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Sub-types: 

0.  The  destination  IMP  cannot  be  reached. 

1.  The  destination  Host  is  not  up. 

2.  Communication  with  the  destination  Host  is  not 
possible  because  it  does  not  have  the  expanded 
(new)  leader  capability  (see  Appendix  A). 

3.  Communication  with  the  destination  Host  is 
administratively  prohibited. 

4-15.  Currently  unused. 

8,  Error  in  Data  -  The  IMP’S  Error  flip-flop  was  set  after 
transmission  of  the  leader  of  a  message  but  before  the 
end  of  the  message. 

9.  Incomplete  Transmission  -  The  transmission  of  the  named 
message  was  incomplete  for  some  reason.  An  incomplete 
transmission  message  is  similar  to  a  RFNM,  but  is  a 
failure  indication  rather  than  a  success  indication. 
Sub-types: 

0.  Destination  Host  did  not  accept  the  message 
quickly  enough. 

1.  Message  was  too  long  (in  excess  of  maximum 
number  of  packets  specified  for  connection). 

2.  The  Host  took  more  than  15  sec.  to  transmit  the 
message  to  the  IMP.  This  time  is  measured  from 
the  last  bit  of  the  leader  through  the  last  bit 
of  the  message. 
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3.  Message  lost  in  the  network  due  to  IMP  or 
circuit  failures. 

4.  The  IMP  could  not  accept  the  entire  message 
within  15  sec.  because  of  unavailable  resources 
(see  Section  3.1 ) . 

5.  Source  IMP  I/O  failure  during  receipt  of  this 
message. 

6-15.  Currently  unused. 

10.  Interface  Reset  -  The  IMP’S  ready  line  has  been  dropped 
and  pending  output  to  the  Host  has  been  discarded  (see 
Section  3.2).  This  probably  indicates  that  the  Host  did 
not  accept  data  from  the  IMP  fast  enough.  Since 
dropping  the  ready  line  also  sets  the  IMP'S  error 
flip-flop,  the  next  message  from  the  Host  will  be 
discarded  and  answered  with  a  type  1  (sub-type  0) 
message.  The  sub-type  field  is  unused. 

11.  Refused ,  Try  Again*  -  A  type  0,  suotype  1  or  2  message 
was  received  from  the  Host  but  a  certain  "non-markable” 
resource  needed  for  sending  the  message  was  not 
available.  The  message  was  discarded,  and  the  Host 
should  try  to  send  it  again  when  best  able  to  do  so. 
Sub-type : 

•The  non-blocking  Host  interface  (see  Section  3.7)  is  not  yet 
implemented . 
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14.  Ready*  The  needed  resource  has  become  available  for 
some  previous  type  0,  subtype  1  or  2  message.  The 
actual  message  is  "named”  by  the  message-id  field. 

15-255.  Unassigned .  Messages  of  other  than  type  0  are  sent  to 
the  Host  prior  to  messages  of  type  0. 

Bits  33  -  40  Handling  Type  - 

The  value  assigned  by  the  source  Host,  this  field  is  used 
only  in  message  types  0,  5i  7-9,  and  11-14. 

Bits  41  -  48  Source  Host  - 
See  Source  IMP,  below. 

Bits  49  -  64  Source  IMP  - 

For  type  0  messages,  these  fields  identify  the  particular 
Host  and  IMP  site  that  originated  the  message.  For  type  4 
messages,  these  fields  identify  the  local  Host  and  IMP,  and 
for  message  types  5-9  and  11-14,  these  fields  identify  the 
particular  Host  and  IMP  site  to  which  a  type  0  message  was 
sent  or  will  be  sent.  The  fields  are  unused  in  all  other 
message  types. 


*'The  non-blocking 
implemented . 

Host 

interface 

(see 

Section 

3.7) 

is 

not 

yet 

•The  non-blocking 
implemented . 

Host 

interface 

( see 

Section 

3.7) 

is 

not 

yet 
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Bits  65  -  76  Message-id  - 

For  message  types  0,  5,  7-9,  and  11-14,  this  is  the  value 
assigned  by  the  source  Host  to  "name"  the  message.  The 
field  is  also  used  by  message  types  2  and  6,  and  unused  by 
all  other  message  types. 

Bits  77  -  80  Sub-type  - 

This  field  is  used  by  message  types  0-2,  4-7,  9,  and  11-12. 
Bits  81  -  96  Message  Length  - 

This  field  is  contained  in  type  0  messages  only,  and  is  the 
actual  length  in  bits  of  the  message  (exclusive  of  leader, 
leader  padding,  and  hardware  padding)  as  computed  by  the 
destination  IMP  using  the  end  of  message  padding 
conventions.  It  should  be  noted  that  the  IMP  will  not 
verify  the  length  of  the  message  if  it  is  specified  by  the 
Host. 

The  following  table  shows  which  non-constant  fields  are  used 
by  each  valid  message  type. 
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Message  Type 


Fields  0  1  2 

Trace  x 

Leader  Flags  x 

Message  Type  x  x  x 

Handling  Type  x 

Source  Host  x 

Message-id  x  x 

Sub-type  x  x  x 

Message  Length  x 


4  5  6  7  8  9  10  11  12  13  14 

XXXXXX  X  X  X  X  X 
X  XXX  xxxx 

XXXXXX  xxxx 

xxxxx  xxxx 

XXXXXX  X  X 


3.5  Word  Length  Mismatch  and  Message  Boundaries 

There  are  two  related  aspects  of  word  length  mismatch: 
first,  the  obvious  need  for  me.ssage  formatting  in  order  for  Host 
computers  having  different  word  lengths  to  communicate;  and, 
second,  the  need  for  locating  the  end  of  a  message,  since 
mismatched  word  lengths  may  lean  to  messages  that  end  in  the 
middle  of  words.  The  IMP  design  guarantees  that  between  Hosts  of 
identical  word  length,  the  natural  word  boundaries  are  preserved. 
Generally,  however,  reformatting  is  left  to  the  Hosts.  The 
problem  of  recognizing  the  end  of  a  message  at  the  receiving  Host 
is  solved  in  the  following  manner.  As  a  message  passes  from  the 
transmitting  Host  to  its  IMP,  the  standard  .Host/IMP  interface 
appends  a  one  to  the  bit  string  when  it  receives  the 
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end-of-message  signal.  This  bit  may  fall  in  any  position  of  an 
IMP  word.  The  hardware  then  fills  any  remaining  bits  of  this  IMP 
word  with  trailing  zeros.  This  process  is  called  IMP  padding. 
The  transmitting  Host  may  also  specify  the  message  length  (in 
bits) ,  which  need  not  be  the  same  as  the  physical  length  of  the 
message. 

As  the  message  is  serially  shifted  to  the  receiving  Host, 
the  last  bit  from  the  IMP  will  generally  fall  somewhere  in  the 
middle  of  the  receiving  Host’s  word.  The  remaining  bits  in  this 
word  are  to  be  filled  in  with  additional  trailing  zeroes  from  the 
Host’s  special  interface  hardware.  (Note  that  a  one  is  purposely 
omitted  here.)  Thus,  the  message  appears  in  the  receiving  Host 
with  a  one  immediately  following  the  last  data  bit  in  the  message 
and  a  string  of  zero  or  more  trailing  zeroes,  that  terminates  at 
a  Host  word  boundary,  following  the  one.  The  last  Host  word  in 
the  received  bit  stream  does  not  necessarily  contain  the  last 
data  bit  in  the  message;  it  may  contain  nothing  but  padding. 

The  maximum  message  that  is  shipped  across  the  interface 
from  the  IMP  to  the  destination  Host  contains  8160  bits  (i.c.,  it 
includes  the  source  IMP'S  padding).  The  destination  Host’s 
special  interface  unit  will  generally  add  padding  of  its  own  to 
round  out  the  total  number  of  bits  going  into  the  Host’s  memory 
to  a  multiple  of  the  destination  Host’s  word  length.  The 
destination  Host  should,  therefore,  be  prepared  to  accept 
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messages  of  at  least  8180  bits.  Not  counting  the  destination 
Host’s  padding,  messages  of  greater  than  8160  bits  in  length 
should  be  discarded  by  the  receiving  Host. 

It  should  be  noted  that  Hosts  may  specify  leader  padding 
(see  Section  3-3,  NOP  message).  This  padding  is  some  integral 
number  of  16-bit  words  which  are  transmitted  and  received 
immediately  following  the  96-bit  leader  of  type  0  messages.  This 
facility  is  designed  to  assist  the  Host  in  aligning  some  portion 
of  the  transmitted  or  received  data  with  its  own  word  boundaries. 
In  particular,  the  Host  may  wish  to  make  the  sum  of  leader, 
leader  padding,  and  other  elements  of  Kost-to-Host  Leader  equal 
to  an  integral  number  of  Host  words.  This  leader  padding  is  not 
counted  in  the  message  length  and  exists  only  across  the  Host/IMP 
interface  (l.e.,  not  in  the  network). 

3.6  Uncontrolled  Packets 

For  certain  limited  experiments  which  are  being  carried  on 
using  the  network,  it  may  be  desirable  for  specified  Hosts  to  be 
able  to  communicate  without  using  the  normal  ordering  and 
error-control  mechanisms  in  the  IMP.  Communication  of  this  type 
is  possible  using  the  Host-to-IMP  and  IMP-to-Host  message  type  0, 
sub-type  3.  The  rules  governing  IMP  handling  of  these  messages 
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1.  Messages  of  type  0,  subtype  3  limited  to  the 

Host-to-IMP  leader  (96  bits)  and  not  more  than  991 
additional  data  hits.  Messages  which  exceed  this  length 
will  be  discarded  without  error  notification. 

2.  At  the  destination  IMP,  these  messages  are  put  on  the 
output  queue  for  the  destination  Host  in  the  order  in 
which  they  are  received;  the  messages  are  likely  to  be 
delivered  in  a  different  order  from  the  order  in  which 
they  were  sent.  Duplicate  copies  of  some  messages  may 
be  delivered. 

3.  There  is  no  source-to-destination  control  of  these 
messages.  Lost  messages  will  not  be  retransmitted.  No 
RFNM,  Incomplete  Transmission,  Destination  Dead,  etc., 
will  be  returned  to  the  source. 

4.  The  same  bit-level  error  control  applied  to  Regular 
messages  will  be  applied  to  these  messages  passing 
between  IMPs;  i.e.,  type  0  subtype  3  messages  are 
delivered  with  a  very  low  probability  of  bit  error. 

5.  If  at  any  time  there  are  insufficient  resources  in  the 
network  to  handle  one  of  these  messages,  it  will  be 
immediately  discarded. 
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6.  Use  of  these  messages  between  two  Hosts  will  not  affect 
use  of  regular  messages  between  these  Hosts.  Regular 
messages  and  subtype  3  messages  may  be  intermixed  over 
the  Host/IMP  interface. 

7,  Uncontrolled  use  of  these  messages  will  degrade  the 
performance  of  the  network  for  all  users.  Therefore, 
ability  to  use  these  messages  will  be  regulated  by  the 
Network  Control  Center  and  will  require  prior 
arrangement  for  each  experiment. 
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3.7  Non-Blocking  Host  Interface* 

As  mentioned  in  Section  3-1,  it  is  sometimes  necessary  for 
the  source  IMP  to  block  the  transmission  of  a  message  from  the 
source  Host.  When  this  blocking  occurs,  all  messages  from  that 
Host  are  held  back,  even  though  some  of  them  might  well  be 
transmitted  unimpeded  if  allowed  into  the  IMP.  Such  might  be  the 
case,  for  example,  if  Host  A  is  sending  to  Hosts  B,  C,  and  D,  and 
the  connection  to  Host  B  has  eight  messages  in  tranoit,  the  firct 
(oldest)  of  which  has  become  lost  in  the  net.  If  a  ninth  message 
is  sent  to  B,  the  interface  will  be  blocked  for  the  duration  of 
the  "incomplete”  timeout  (30-45  seconds),  waiting  for  a  message 
slot  to  become  available  on  that  connection.  During  this  time, 
however,  it  would  have  been  possible  for  A  to  send  messages  to  C 
and  D,  had  the  interface  not  been  blocked. 

The  non-blocking  Host  interface  is  a  software  mechanism 
which  provides  the  source  Host  with  the  capability  of  keeping  the 
interface  unblocked  for  the  vast  majority  of  situations  under 
which  it  might  otherwise  have  become  blocked.  There  will  still 
be  a  few  circumstances,  associated  with  bandwidth  and  storage 
limitations  of  the  source  IMP,  under  which  the  interface  may  be 
blocked  regardless  of  the  mechanism  used  by  the  Host. 


•This  section  is  a  preliminary  specification  and  is  still  subject 
to  modification.  The  extensions  required  to  the  Host/IMP 
protocol  have  not  yet  been  implemented. 
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The  non-blocking  mechanism  works  by  allowing  the  Host  to 
flag  some  or  all  of  its  type  0  messages  as  "refusable",  thus 
allowing  the  IMP  to  discard  them  if  they  would  otherwise  block 
the  interface.  In  such  a  case,  not  only  is  the  Host  notified 
that  the  message  was  discarded,  but  it  is  also  given  guidance  as 
to  when  the  message  should  be  retransmitted.  In  most  cases,  the 
particular  resource  that  was  missing  is  "markable",  and  the  Host 
can  be  notified  when  the  resource  becomes  available.  In  some 
cases,  the  resource  is  not  "markable",  and  the  Host  must  simply 
retransmit  in  accordance  with  its  own  requirements.  The  specific 
protocol  for  this  mechanism  is  now  described. 

Host-to-IMP  type  0  messages  have  four  subtypes: 
Non-refusable,  Refusable ,  Get  Ready,  and  Uncontrolled .  The 
uncontrolled  subtype,  described  in  Section  3*6,  is  never  refused. 


and  because  it  does 

not 

require  most  of 

the 

resources  of 

"controlled"  messages. 

is 

seldom  blocked. 

The 

Non-refusable 

subtype  is  the  standard  mode  of  operation,  which  can  cause 
interface  blocking  under  the  various  circumstances  described  in 
Section  3*1.  The  Refusable  subtype  is  treated  identically  to  the 
Non-refusable  subtype  if  blocking  is  not  necessary.  Under  most 
circumstances  where  blocking  would  have  been  necessary,  however, 
this  message  subtype  is  discarded,  and  one  of  three  types  of 
IMP-to-Host  messages  sent  back  to  the  Host.  A  Refused ,  Try  Again 
(type  11)  message  indicates  a  "non-markable"  resource  was 
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required,  and  the  Host  should  merely  retransmit  at  its 
convenience.  A  Refused,  Will  Notify  (type  12)  message  indicates 
a  ’’markable”  resource  was  required.  The  Host  should  wait  for  a 
fourth  IMP-to-Host  message  type,  Ready  (type  14),  before 
retransmitting.  The  IMP  will  send  the  Ready  when  the  resource 
becomes  available.  A  Refused.  Still  Trying  (type  13)  message 
indicates  that  the  IMP  has  already  given  a  Refused,  Will  Notify 
on  that  connection,  but  has  not  yet  sent  the  Ready  (it  will  only 
queue  one  such  response  at  a  time  for  any  connection).  There  is 
no  additional  response  after  the  Refused.  Still  Trying,  and  the 
Host  should  queue  the  message  to  be  retransmitted  after  the  one 
for  which  the  Ready  is  expected. 

The  Get  Ready  subtype  of  the  type  0  Host-to-IMP  message  is 
not  a  real  message  in  the  sense  that  it  contains  only  the  leader 
of  an  intended  (future)  message.  It  is  provided  so  that  the  Host 
can  determine  whether  or  not  a  message  could  get  through  without 
blocking,  without  actually  sending  the  data  in  the  message 
through  the  interface.  The  possible  responses  to  this  subtype 
are  identical  to  those  of  the  Refusable  subtype,  except  that  in 
the  normal  case,  when  the  Refusable  message  would  have  been 
transmitted  to  the  destination  without  any  interface  blocking 
followed  eventually  by  a  RFNM,  the  IMP'S  response  to  the  Get 
Readv  is  to  send  a  Ready  back  to  the  Host. 
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Finally,  it  should  be  noted  that  a  Ready  does  not  guarantee 
that  a  retransmission  will  not  be  blocked,  since  no  ref.ources  are 
actually  reserved  for  some  particular  message- id ,  and  in  fact 
many  are  shared  by  all  connections.  The  best  strategy  for  the 
Host  willing  to  use  the  non-blocking  feature  is  to  make  all 
messages  Refusable ,  even  when  responding  to  a  Ready . 
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4.  HARDWARE  REQUIREMENTS  AND  DESCRIPTION 


A  local  Host  is  connected  to  the  IMP  through  a  Host  cable 


(provided  with  the  IMP),  which  joins  a  standard  Host/IMP 


interface  unit  in  the  IMP  to  a  special  Host/IMP  interface  unit  in 


the  Host.  A  distant  Host  is  connected  to  an  augmented  standard 


Host/IMP  interface  through  a  cable  provided  by  the  Host.  The 


structure  of  the  standard  Host/IMP  interface,  the  IMP/Host 


handshaking  procedure,  the  end-of-message  indication,  the  Master 


Ready  lines,  and  the  signals  on  the  Host  cable  are  all  described 


in  detail  below.  A  very  distant  Host  is  connected  via 


communications  circuits  to  a  modem  interface  unit  as  described 


in  Appendix  F. 


The  special  interface  should  be  designed  by  the  Host 


personnel  to  operate  in  conjunction  with  the  standard  Host/IMP 


interface  or  the  augmented  interface  as  the  case  may  be.  We  have 


not.  however,  attempted  to  soecifv  the  special  Host/IMP  interface 


in  any  detail.  We  recommend  that  the  special  interface  be 


modeled  after  the  standard  interface,  and,  in  the  remainder  of 


this  section,  we  assume  that  it  will  be.  It  should  be  noted  that 


the  special  interface  must  be  operated  in  a  full  duplex  mode.*  A 


simplified  schematic  drawing  of  a  special  Host/IMP  interface  is 


^Those  few  ~Rosts  which  originally  implemented  half  duplex 
interfaces  have  had  inordinate  difficulties  of  various  kinds. 
See,  for  example,  Section  3.1. 
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included  in  Appendix  B  to  assist  Host  personnel  in  the  design  of 
the  special  interface.  The  distant  Host  modification  to  the 
standard  interface  affects  only  the  cable  and  the  method  of  cable 
driving;  it  does  not  change  the  basic  operation  of  the  interface. 


4.1  Structure  of  the  Standard  Host/IMP  Interface 


Figure  4-1  Simplified  Illustration  of  Host/IMP  Interface 
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receiver’s  memory.  The  transmission  thus  consists  of  a  bit 
stream  containing  no  special  indications  of  word  boundaries  but 
delayed  occasionally  while  the  sender  fetches,  or  the  receiver 
stores,  a  word.  The  high«order  bit  of  each  word  is  transmitted 
first . 

Bit  transfer  is  asynchronous,  the  transmission  of  each  bit 
being  controlled  by  a  Ready«For^Next-Bit,  There’ s«Your»Blt 
handshaking  procedure.  Each  bit  is  transferred  only  when  both 
sender  and  receiver  indicate  preparedness.  This  permits  either 
the  sender  or  the  receiver  to  hold  up  the  transmission  between 
any  two  bits  in  order  to  take  as  much  time  as  necessary  to  get  a 
new  word  from  memory,  to  tuck  an  assembled  word  into  memory,  or 
to  activate  an  interrupt  routine  that  sets  up  new  input  or  output 
buffers.  Neither  the  sender  nor  the  receiver  should  expect 
transmission  to  take  place  at  a  pre-determined  bit  rate  and  each 
must  be  able  to  accept  arbitrary  delays  introduced  by  the  other 
at  any  point  in  the  bit  stream. 

The  design  of  an  asynchronous  interface  was  selected  for  two 
reasons:  first,  because  of  the  inherently  asynchronous  nature  of 
the  process  by  which  words  of  one  length  are  fetched  from  one 
machine  and  reformed  into  words  of  another  length  and  stored  in 
another  machine;  and,  secondly,  because  such  a  design  allows  a 
variety  of  special  Host/IMP  interfaces  to  be  designed  independent 
of  stringent  timing  specifications  that  may  be  difficult  or 
impossible  for  certain  Hosts  to  meet. 
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4.2  IMP/Host  Handshaking 

Figure  4-2  shows  a  much  simplified  version  of  the  control 
logic  for  the  bit-by-bit  handshaking  procedure.  When  PG  #1 
(Pulse  Generator)  fires,  it  turns  off  the  Bit  Available  flip-flop 
and  a  new  data  bit  is  shifted  into  position  by  the  sender.  The 
Bit  Available  flip-flop  is  then  turned  back  on,  and,  if  (or  when) 
the  receiver  is  ready  to  receive  a  bit,  a  There*  s-Your-Bit  signal 
is  sent  to  him.  This  triggers  PG  #2»  which  shifts  in  the  new  bit 
and  shuts  off  the  Ready-For-Next-Bit  flip-flop.  When  this 
indicator  goes  off,  the  sender  knows  that  the  bit  has  been  taken 
by  the  receiver.  PG  II  then  fires  and  shuts  off  the  Bit 
Available  flip-flop  in  preparation  for  getting  the  next  bit  ready 
for  transmission.  After  the  receiver  has  taken  in  the  bit  and  is 
ready  to  accept  a  new  one,  it  turns  the  Ready-For-Next-Bit 
flip-flop  back  on.  The  cycle  then  repeats. 

Each  time  the  sender  is  notified  that  a  bit  has  been 
accepted  (by  the  on;  transition  of  Ready-For-Next-Bit),  a  word 
length  counter  is  checked  to  see  whether  a  new  word  must  be 
fetched  from  memory.  Similarly  when  a  bit  is  accepted  at  the 
receiver,  it  may  be  necessary  to  tuck  an  assembled  word  into  the 
memory  before  registering  readiness  to  receive  anther  bit.  In 
addition  to  these  obvious  requirements,  the  simplified  picture 

•The  on  (t )  transition  of  There* s-Your-Bit  triggers  PG  #2.  The 
off  (IT  transition  of  Ready-For-Next-Bit  triggers  PG  #1 . 
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contains  critical  race  problems*,  which  have  been  carefully 
resolved  in  the  IMP'S  interface  and  must  be  similarly  resolved  in 
the  Host's  special  interface. 

The  receiver  may  choose  either  of  two  methods  of 
handshaking,  a  two-way  or  a  four-way  handshake.  In  the  four-way 
handshake,  the  receiver  awaits  the  dropping  of  There' s-Your-Bit 
before  raising  Ready-For-Next-Bit.  A  full  cycle  of  the  four-way 
handshake  works  as  follows:  The  sender  readies  the  next  data  bit 
and  the  There' s-Your-Bit  signal  is  sent  to  the  receiver  (1st 
cable  transit).  The  receiver  takes  in  the  bit  and  notifies  the 
sender  by  dropping  Ready-For-Next-Bit  (2nd  cable  transit).  The 
sender  responds  by  dropping  the  There' s-Your-Bit  signal  (3»"d 
cable  transit)  and  after  the  receiver  has  noted  this,  the 
Ready-For-Next-Bit  signal  can  be  turned  back  on  (4th  cable 
transit),  registering  preparedness  for  a  new  bit. 

The  two-way  handshake  works  as  follows:  The  sender  readies 
the  next  data  bit  and  the  There' s-Your-Bit  signal  is  sent  to  the 
receiver  (1st  cable  transit).  The  receiver  takes  in  the  bit  and 
notifies  the  sender  by  dropping  Ready-For-Next-Bit  (2nd  cable 
transit) .  Instead  of  waiting  for  this  signal  to  propagate  to  the 
sender  and  the  resultant  dropping  of  There' s-Your-Bi t  to  return, 
the  receiver  holds  Ready-For-Next-Bit  off  for  a  brief  period  and 
then  turns  it  back  on. 

*For  example,  the  race  in  shutting  off  the  Ready-For-Next-Bit 
flip-flop. 


."w*, 
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This  method  has  two  dangers  that  must  be  considered,  both 
arising  from  the  situation  where  Ready-For-Next-Bit  is  off  for 
too  short  a  time. 

1.  If  Ready-For-Next-Bit  is  off  for  too  short  a  period,  the 
sender  may  never  note  that  it  went  off  and  he  will 
continue  to  wait  for  the  bit  to  be  taken.  The  IMP 
itself  requires  that  the  signal  be  off  at  the  IMP  end  of 
the  cable  for  at  least  50  nanoseconds  for  local  Hosts 
and  for  at  least  1  usee  for  distant  Hosts.* 

2.  If  the  receiver  turns  Ready-For-Next-Bit  back  on  before 

the  There* s-Your-Bit  signal  has  been  observed  to  go  off 
at  the  receiver's  end  of  the  cable,  then  the  receiver 
may  mistakenly  believe  the  new  bit  is  ready  to  be  taken 
in.  This  problem  is  avoided  if  the  receiver  maintains  a 
There*  s-Your-Next-Bit  flip-flop  which  is  turned  off  when 
Ready-For-Next-Bit  is  turned  off  and  is  turned  on  only 
by  the  leading  edge  (£n  transition)  of  the 

There* s-Your-Bit  signal  from  the  sender. 


'The  316  and  516  IMPS,  in  fact,  always  use  the  two-way  procedure. 
They  do  not  wait  for  the  There* s-Your-Host-Bi t  signal  to  go  off 
but  instead  guarantee  to  hold  the  Ready-For-Next-Host-Bit  signal 
off  for  at  least  1  usee.  The  Pluribus  IMP  uses  the  four-way 
handshake . 
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For  local  Hosts,  where  the  cable  delays  are  not  significant, 
either  handshake  procedure  may  be  used.  For  distant  Hosts,  where 
cable  delays  may  be  significant,  the  two-way  handshake  procedure 
is  recommended,  in  order  to  avoid  placing  an  unnecessary 
restriction  on  the  maximum  bit  rate. 

The  IMP  introduces  some  deliberate  delays  into  this  control 
loop,  both  as  a  sender  and  as  a  receiver.  Specifically,  as  a 
sender,  the  IMP  introduces  approximately  10  usee  of  delay* 
between  the  time  that  the  Host  indicates  that  it  has  taken  one 
bit  and  the  time  that  the  next  bit  is  made  available.  As  a 
receiver,  the  IMP  shifts  in  the  data  bit  and  turns  off  the 
Ready-For-Next-Bit  signal  shortly  after  the  There* s-Your-Bit 
signal  comes  on.  However,  Ready-For-Next-Bit  will  not  be  turned 
on  again  until  about  10  usee*  after  There* s-Your-Bit  comes  on. 
By  introducing  these  deliberate  delays,  the  IMP  slows  down  the 
rate  of  Information  flow  on  the  Host  channels,  thereby 
controlling  the  maximum  amount  of  IMP  memory  bandwidth  that  the 
channels  can  consume.  This  control  is  essential  to  avoid 
usurping  bandwidth  required  for  the  store-and- forward  functioning 
of  the  IMP. 


*^these  are  minimum  times  assuming  no  IMP  memory  reference  is 
required.  Where  a  memory  fetch  or  store  is  required,  the  times 
will  be  increased  by  at  least  4  usee. 
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padding  bits  will  then  be  shifted  into  the  register,  namely  a 
single  one  followed  by  enough  zeroes  (perhaps  none)  to  fill  up 
the  register.  These  additional  bits  are  appended  at  the  end  of  a 
Host  message  by  the  hardware  in  the  input  section  of  the 
standard  interface.  If  the  last  data  bit  happens  to  just  fill 
the  shift  register,  an  additional  IMP  word  consisting  of  a  single 
one  followed  by  fifteen  zeroes  will  be  appended  to  the  message. 
Alternatively,  if  the  single  one  happens  to  just  fill  the  shift 
register,  the  IMP  padding  will  contain  only  this  single  one.  At 
the  destination,  the  IMP  will  indicate  the  end  of  the  message  to 
its  Host  by  presenting  a  Last-IMP«Bit  signal  to  the  Host  together 
with  the  last  bit  of  the  IMP  padding.  In  general,  this  signal 
will  occur  somewhere  in  the  middle  of  a  Host  word,  i.e.,  with  the 
input  shift  register  in  the  special  interface  only  partially 
loaded.  The  Host  must  shift  enough  additional  zeroes  (perhaps 
.lone)  into  this  register  to  fill  up  the  register. 

4.4  Master  Ready  Lines 

Whenever  the  IMP  is  ready,  it  holds  closed  a  relay  contact 
that  connects  two  wires  (the  IMP  Master  Ready  and  the  IMP  Ready 
Test  lines)  in  the  Host  cable.  Figure  4-3  illustrates  how  the 
Host  can  employ  this  contact  closure  to  ground  a  clamped  logic 
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Master  Ready  signal  passes  through  a  relay,  it  will,  in  general, 
show  contact  bounce.  When  the  IMP  becomes  ready  (i.e.,  closes 
its  relay),  it  executes  a  programmed  delay  before  the 
There* s-Your-IMP-Bit  line  becomes  true.  This  delay  covers  the 
contact  bounce  period  and  thus  the  Host  need  not  worry  about 
bounce  on  the  gated  versions  of  this  signal.  (The  IMP  also 
executes  a  programmed  delay  before  beginning  a  new  input 
operation.  Since  there  may  however  be  errors  in  the  current 
transmission  to  the  IMP,  the  Host  should  always  send  at  least  one 
NOP  message  after  seeing  the  IMP  in  a  not-Ready  state.) 


The  Host  should  provide  similar  protection  by  not  permitting 
the  There* s-Your-Host-Bit  signal  to  become  true  until  after  its 
relay  contacts  have  solidly  finished  closing. 

4.5  Host  Cable  Connections 

following  is  a  summary  of  the  signals  on  the  Host  cable: 


1.  IMP  Master  Ready  -  The  return  for  the  IMP  Ready  Teat 
signal  through  the  IMP* a  relay  contact. 


2.  IMP  Ready  Teat  - 

The  test  signal 

sent 

to  the 

IMP 

to 

interrogate  its 

ready  status 

through  the  IMP 

*s  relay 

contacts.  No  more  than  IOC  ma. 

should 

flow 

in 

this 

wire  and  the  IMP  Master  Ready  wire. 
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line  whose  polarity  indicates  readiness  of  the  IMP*.  Note  that, 


if  the  cable  is  removed  at  either  end,  the  IMP  appears  to  the 


Host  not  to  be  ready.  The  relay  contacts  are  a  Normally-Open 


pair  and  thus,  if  the  IMP*s  power  goes  off,  the  line  indicates 


"not  ready". 


The  relay  closure  is  also  controlled  by  the  IMP  program.  If 


the  IMP  detects  a  serious  program  failure,  it  initiates  an 


automatic  recovery  procedure.  This  same  procedure  is  also 


initiated  by  the  Network  Control  Center  under  certain  conditions. 


Execution  of  the  recovery  procedure  causes  the  relay  to  open; 


successful  recovery  will  eventually  cause  the  relay  to  close 


again. 


Similarly,  each  Host  must  provide  for  its  IMP  a  set  of 


contacts,  which  open  when  Host  power  goes  off  or  whenever  the 


Host  does  not  wish  to  communicate  with  the  rest  of  the  network 


for  an  extended  period. ••  The  IMP  will  use  this  contact,  in  the 


specific  manner  suggested  above,  to  pass  a  signal  ground  around 


to  itself  for  testing  Host  readiness. 


The  special  Host  Interface  should  gate  all  incoming  signals 


with  the  signal  (or  its  inverse)  on  the  IMP  Master  Ready  line  in 


order  to  avoid  responding  to  meaningless  transitions.  Since  the 


•The  choice  of  ground  as  the  interrogation  level  is  obviously 
arbitrary,  and  the  Host  may  use  any  reasonable  arrangement. 

••See  Section  3*2  for  a  more  complete  discussion  of  the 
alternatives  available  to  the  Host  for  voluntarily  stopping 
communication  with  the  rest  of  the  network. 
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itself.* 

7.  Ready-For-Next-Host-Bit  -  This  signal  will  be  presented 
to  the  Host  whenever  the  IMP  is  waiting  for  a 
transmission  by  the  Host.  Each  time  that  the  Host  gives 
the  IMP  a  bit  (via  There* s-Your-Host-Bi t) ,  the 
Ready-For-Next-Host-Bit  will  go  off  after  the  bit  has 
been  taken  in.  It  will  go  back  on  again  within  10  usee 
unless  a  memory  access  is  required  (once  every  16  bits). 
A  much  longer  off  period  will  result  when  an  IMP  memory 
buffer  region  fills,  and  an  interrupt  service  routine 
must  operate  before  the  IMP  is  ready  for  another  bit. 

Last-Host-Bit  -  When  the  Host  transmits  the  last  bit  of 
a  message,  the  Last-Host-Bit  signal  should  be  sent  to 
the  IMP  in  conjunction  with  the  There* s-Your-Host-Bi t 
signal.  Specifically,  the  Last-Host-Bit  signal  must 
come  on  no  later  than  the  There* s-Your-Host-Bit  signal 
comes  on,  and  should  remain  on  at  least  until 
Ready-For-Next-Host-Bit  goes  off.  The  IMP  will  pad  the 
message  with  a  one  followed  by  enough  zeroes  (perhaps 
none)  to  fill  the  current  IMP  word. 


*At  first  glance  this  seems  like  duplication.  However,  when  the 
next  bit  becomes  available,  the  Bit  Available  flip-flop  will  be 
turned  back  on  and  yet  the  There* s-Your-Bit  signal  should  not  be 
sent  unless  the  Ready-For-Next-Bit  signal  is  on.  Thus,  the  need 
for  the  AND  gate.  Shutting  off  Bit  Available  is  required  to 
avoid  confusing  the  receiver  with  an  old  bit  when  a  new 
Ready-For-Next-Bit  signal  comes  on. 
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Host  Master  Ready  -  The  return  for  the  Host-Ready-Test 
signal  through  the  Host's  relay  contact. 

Host  Ready  Test  -  The  ground  signal  sent  to  the  Host  to 
interrogate  its  ready  status  through  the  Host's  relay 
contacts.  No  more  than  100  ma.  should  flow  in  this 
wire  and  the  Host  Master  Ready  wire. 

Host-to-IMP  Data  Lines  -  The  data  from  the  Host  should 
be  changed  for  successive  bits  only  after  the  IMF's 
Ready-For-Next-Host-Bit  signal  goes  off  indicating  that 
the  previous  bit  has  been  selected. 

There' s-Your-Host-Bl t  -  This  signal  should  be  presented 
to  the  IMP  by  the  Host  as  soon  as  the  Host  has  a  bit 
available  to  transmit  and  the  IMP  is  indicating  that  it 
is  Ready  For  Next  Host  Bit.  When  the 
Ready-For-Next-Host-Bit  signal  goes  off,  the 
There' s-Your-Host-Bit  signal  should  be  removed.  This 
must  be  done  in  two  ways,  as  shown  in  Figure  4-2  -- 
first  by  the  AND  gate  between  the  Bit  Available 
flip-flop  and  the  Ready-For-Next-Bit  signal,  and  second 
by  immediately  turning  off  the  Bit  Available  flip-flop 
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9.  iMP-to-Host  Data  Line  -  The  data  for  the  Host  will  be 
changed  for  successive  bits  only  after  the  Host's 
Ready-For-Next-IMP-Bit  signal  goes  off,  indicating  that 
the  previous  bit  has  been  accepted. 

10.  There' s-Your-IMP-Bit  -  This  signal  will  be  presented  to 

the  Host  by  the  IMP  as  soon  as  the  IMP  has  a  bit 
available  to  transmit  and  the  Host  presents  the 
Ready-For-Next-IMP-Bit  signal.  When  the 

Ready-For-Next-IMP-Bit  goes  off,  the 

There* s-iour-IMP-Bit  signal  will  be  removed.  It  will 
not  be  renewed  until  a  new  Ready-For-Next-IMP-Bit  signal 
arrives. 

11.  Ready-For-Next-IMP-Bit  -  This  signal  should  be  presented 

to  the  IMP  whenever  the  Host  is  ready  to  receive 

information.  Each  time  that  the  IMP  gives  the  Host  a 
bit  (via  the  There' s-Your-IMP-Bit  line),  the 
Ready-For-Next-IMP-Bit  signal  should  go  off  after  the 
bit  has  been  taken  in.  This  notifies  the  IMP  that  the 
bit  has  been  taken  and  that  a  new  bit  can  be  moved  into 
position  and  made  available.  Ready-For-Next-IMP-Bit 

should  be  off  for  at  least  50  nanoseconds  (1  usee  for 
distant  Hosts)  as  seen  at  the  IMP  before  it  goes  back  on 
again.  It  may,  of  course,  be  off  for  as  long  as  it  takes 
the  Host  to  ready  itself  to  receive  the  next  bit. 
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12.  Last-IMP-Bit  -  When  the  IMF  transmits  the  last  bit  of 
the  source  IMP*s  padding,  the  Last-IMP-Bit  signal  will 


be  sent  to 

the  Host 

in 

conjunction  with 

the 

There*  s-Your- 

IMP-Bit 

signal . 

Specifically, 

the 

Last-IMP-Bit 

signal  will 

come 

on  no  later  than 

the 

There* s-Your-IMP-Bit  signal.  Last-IMP-Bit  will  stay  on 
for  some  arbitrary  short  time  after  There* s-Your-IMP-Bit 
goes  off.  The  Host*s  interface  must  not  interrogate 
this  line  after  the  P.eady-Fo'*-Ne**'-IMP-Bl t  signal  has 
been  turned  off.  The  Host*s  special  interface  should 
round  out  the  last  memory  word  with  zeroes,  as  required. 

The  asynchronous  (i.e.,  sequential)  nature  of  the  interface 
causes  stress  to  be  laid  on  the  order  in  which  operations  occur 
rather  than  on  their  timing .  Minimum  on  or  off  times  for  the 
circuits  in  the  IMP  are  50  nanoseconds  for  a  local  Host  and  1 
usee  for  a  distant  Host.  Thus,  for  example,  the  Host*s 
Ready-For-Next-IMP-Bit  line  must  be  visibly  down  at  the  IMP  for 
at  least  this  length  of  time  before  it  is  brought  back  up  even  if 
the  Host  takes  the  bit  more  quickly  than  that.  Similarly,  the 
Host*s  Bit  Available  flip-flop  must  appear  off  to  the  IMP  (via 
the  There*  s-Your-Host-Bit  line)  fO'*  50  nanoseconds  for 
local  Hosts  and  1  usee  for  distant  Hosts.  The  IMP  delays  only  a 
very  short  time  from  the  arrival  of  There* s-Your-Host-Bit  before 
taking  the  Host* a  date  bit  or  checking  the  Last-Host-Bit  line. 
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However,  for  IMP-to-Host  transmission,  the  IMP  will  guarantee 
that  the  IMP  data  bit  is  on  the  line  and  the  Last-IMP-Bit  level 
is  correct  at  least  500  nanoseconds  before  turning  on  the 
There* s-Your-IMF-Bit  signal.  Thus,  skews  of  under  500 
nanoseconds  in  the  signals  for  IMP-to-Host  transmission  at  the 
IMP  end  of  the  cable  will  be  removed  by  the  IMP,  but  skews  for 
Host-to-IMP  transmission  must  be  removed  by  the  Host. 


4.5.1  Connection  to  a  Local  Host 

The  nominal  asserted  level  for  all  logic  lines  (Data, 
Ready-For-Next-Bit,  There* s-Your-Bit,  Last  Bit)  is  ♦5  volts  and 
the  unasserted  level  is  ground  (these  are  with  respect  to  the  IMP 
signal  ground).  The  driving  and  receiving  circuits  and 
specifications  are  shown  in  Appendix  C. 

The  Host  cable  supplied  with  the  516  IMP  and  the  Pluribus 
IMP  is  30  feet  long  and  contains  12  RG  174/U  coaxial  conductors 
with  grounded  shields.  Host  personnel  must  provide  an 
appropriate  connector  for  the  Host  end  of  the  cable.  The  shield 
of  each  conductor  is  connected  to  signal  ground  at  the  IMP 
connector.  Each  cable  is  labelled  with  the  IMP  connector  pin 
number  corresponding  to  the  center  lead  of  the  coaxial  conductor. 
These  wires  are  assigned  as  indicated  in  figure  4-4  for  the  5l6 
IHP;  that  is,  the  number  in  the  figure  corresponds  to  the  number 
of  the  label  attached  to  each  coaxial  conductor.  Muribus  IMP 
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connections  are  pictured  in  Figure  4-6.  All  shields  should  be 
connected  to  signal  ground  in  the  Host.  DC  amplifiers  are  used 
for  line  driving  and,  by  this  means,  we  expect  to  couple  the 
signal  ground  systems  as  tightly  as  possible. 

The  Host  cable  supplied  with  the  316  IMP  is  30  feet  long  and 
contains  32  twisted  pairs.  The  cable  is  terminated  at  the  IMP 
end  with  a  paddle  card  which  plugs  directly  into  the  316  Host 
interface.  Each  pair  of  the  cable  consists  of  a  colored  wire  and 
a  black  wire  numbered  with  the  pin  number  of  the  paddle  card  to 
which  the  colored  wire  is  connected.  All  black  wires  connect  to 
the  paddle  card  signal  ground.  Host  personnel  must  provide  an 
appropriate  connector  for  the  Host  end  of  the  cable.  The  wires 
are  assigned  as  in  Figure  4-5.  All  twisted  pair  grounds  should 
be  connected  to  signal  ground  in  the  Host.  DC  amplifiers  are 
used  for  line  drivers  and  the  signal  ground  systems  of  the  Host 
and  IMP  should  be  as  highly  coupled  as  possible. 

4.5.2  Connection  to  a  Distant  Host 

Connection  to  a  distant  Host  necessitates  the  use  of 
balanced  lines  and  requires  that  a  Host  pay  careful  attention  to 
differentials  in  ground  potential.  The  distant  Host's  special 
interface  must  provide  balanced  drivers  and  receiver*.  Ground 
isolation  is  provided  by  the  IMP. 
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The  Host  must  supply  a  shielded  cable  containing  multiple 
twisted  pairs  of  #20  (or  heavier)  gauge  wire;  The  characteristic 
impedance  (ZO)  must  be  approximately  120  ohms.  The  wires  may  be 
either  individually  shielded  or  may  have  a  single  shield  covering 
/  all  pairs.  The  shield  is  used  to  carry  the  Host's  ground 

reference  and  should  have  very  low  resistance.  There  must  be  at 
last  10  pairs  in  tne  uatlc,  and  strongly  recommend  that  at 
least  two  spare  pairs  be  carried  (see  Figure  4-7).  A  suitable 
cable  is  Direct  Burial  Cable,  REA  Specification  PE-23f  19AWG 
conductors,  12  pairs. 

At  the  IMP  side  the  cable  must  be  terminated  in  an 

MS24266R18B31PN  (Amphenol  43-16R18-31P)  plug  with  an  MS27291-5 
clamp  and  MS24254-20P  contacts  for  316  and  516  IMPS.  For  distant 
host  connections  to  Pluribus  IMPS,  the  cable  must  be  terminated 
in  a  Cinch  DC-37P  or  equivalent,  with  Cannon  D-1 10273  disc 
latches  and  (recommended)  Amphenol  17-1373  shell  and  strain 
relief.  The  outer  sheath  of  the  cable  should  be  stripped  back  at 
least  two  feet  to  allow  flexibility  at  the  connector  when  the 
DC-37P  is  used.  Pair  and  pin  assignments  are  shown  in  figures 
4-7A  (316  and  516)  and  4-7B  (Pluribus).  Note  that  the  cable 

shi.id(s)  should  be  connected  to  connector  pins  as  specified,  and 
NOT  to  the  connector  shell.  For  Pluribus  installations  where  the 
site  already  has  a  cable  terminated  in  the  Amphenol  MS  style 

connector,  BBN  can  supply  a  short  adapter  cable  having 

appropriate  connectors  on  both  ends. 
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The  cable  shields  should  be  very  solidly  connected  to  the 
Host’s  signal  ground,  which  should  be  connected  to  the  third-wire 
power  ground  at  the  Host  computer .  DC  isolation  is  done  at  the 
IMP  end  of  the  cable  to  prevent  significant  currents  from  flowing 
through  the  shields.  This  isolation  is  accomplished  by  optically 
isolating  the  signals.  All  signals  from  the  distant  Host  must 
have  transition  times  of  less  than  100  nanoseconds,  and  must 
remain  in  each  state  for  at  least  1  usee  between  transitions. 

The  logic  signals  on  the  pairs  of  the  cable  (Data, 
Ready-For-Next-Bit  There’ s-Your-Bit  Last-Bit)  are  balanced 
voltage  signals  with  each  aide  terminated  at  the  driver  in  62 
ohms  to  ground.  Thus,  the  terminating  impedance  is  124  ohms  and 
matches  the  cable  impedance.  The  asserted  logic  signal  drives 
the  odd-numbered  connector  pin  of  each  pair  to  >0.5  volts,  and 
the  other  pin  to  -0.5  volts,  producing  a  differential  signal  of 
1.0  volt.  The  unasserted  signal  switches  the  polarity  of  this 
pair.  There  is  no  voltage  drop  across  the  cable  since  the 
receiver  is  unterminated.  This  produces  a  step  reflection  at  the 
receiver  which  is  absorbed  at  the  transmitter.  At  the  Host  end 
the  transmitters  should  terminate  the  cable  in  120  ohms  across 
each  signal  pair. 

Standard  6-volt  IMP  logic  signals  are  converted  to 
differential  signals  by  the  line  drivers  and  from  differential 
signals  to  6  volt  logical  signals  by  the  receivers.  Drawings  for 
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APPENDIX  A 

Appendix  A  has  been  removed. 
The  Information  contained  In 
this  appendix  Is  obsolete. 
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OF  THE  HOST/IMP  INTERFACE 
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This  Appendix  recommends  a  plan  for  Host  implementation,  of 
the  Host/IMP  interface,  both  the  hardware  and  the  lowest-level 
Host  software  which  drives  the  hardware.  In  particular,  the 
software  discussed  here  has  the  tasks  of  input  and  output, 
detection  of  errors,  and  management  of  the  Ready  lines.  Figures 
B-1  and  B-2  provide  simplified  schematic  drawings  of  the  Host 
interface  hardware. 

B.1  Ready  Line  Philosophy 

The  actions  which  should  be  taken  when  transitions  occur  on 
the  Ready  line  have  the  objective  of  reliably  resynchronizing 
transmission  after  a  temporary  lapse  of  service,  and  possible 
loss  of  state  information  by  either  the  IMP  or  the  Host. 

First,  consider  the  IMP  Ready  line.  When  it  drops,  the  IMP 
has  suffered  a  possible  loss  of  state,  so  the  message  in  transit 
from  the  IMP  to  the  Host  (if  any)  is  likely  to  be  incomplete. 
Similarly,  the  message  in  transit  from  the  Host  to  the  IMP  (if 
any)  is  likely  to  be  incomplete.  Both  the  Host  and  the  IMP  must 
recognize  this  explicitly  by  sending  a  message  intended  to  be 
discarded  (for  example,  a  NOP)  and  discarding  the  message 
currently  being  received.  (Note  that  the  discardable  message  may 
be  appended  to  some  other  message  already  partly  received.) 

The  simplest  arrangement  for  the  Host's  interface  driver  is 
a  pair  of  processes,  one  sending  messages  and  the  other  receiving 
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A  drop  of  the  IMP’S  ready  line  must  be  provided  as  an 
error  status  bit  to  each  process.  However,  the  Cwo  processes 
will  need  to  clear  this  condition  independently:  the  simplest 
implementation  is  an  Input  Error  flop  and  an  Output  Error  flop. 
Both  flops  are  set  by  a  drop  of  the  IMP’S  ready  line,  and  they 
are  cleared  independently  under  program  control. 

Vhen  the  IMP  raises  its  ready  line,  each  contact  bounce  will 
again  set  the  Error  flops  in  the  Host’s  interface.  To  insure 
that  messages  are  not  flowing  across  the  interface  at  this  time, 
assertions  of  the  signals  There’ s-Tour-IMP-Bit  and 
Ready-For-Next-Host-Bit  have  been  delayed  sufficiently  in  the  IMP 
to  guarantee  that  the  IMP  ready  line  has  stabilized. 
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B.2  Programming  the  I/O  Routines 

System  startup  or  restart  requires  the  Initialization  step 
of  clearing  the  Host  Ready  flop  (driving  the  relay  controlling 
the  Host  Reauy  line),  waiting  at  least  1/2  second,  and  setting 
the  Host  Ready  flop.  Restarting  the  following  two  (asynchronous) 
Interface  driver  processes  will  then  properly  resynchronize 
Host-IMP  communication. 

INPUT:  Walt  until  an  Input  buffer  Is  available 

Walt  until  IMP  ready 
Start  Input 

Walt  until  Input  Is  complete 

IF  Input  Error 

THEN  clear  Input  Error 

Comment:  Discard  erroneous  message;  reuse 
buffer 

ELSE  queue  message  on  Input  queue 
GOTO  INPUT 
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OUTPUT:  Walt  until  a  message  is  present  on  output  queue 
Wait  until  IMP  ready 
Start  output 

Wait  until  output  is  complete 

IF  Output  Error 

THEN  clear  Output  Error 

Comment:  Save  erroneous  message  for 
retransmission 

ELSE  remove  message  from  output  queue 
GOTO  OUTPUT 

The  IMP  Ready  line  and  error  flops  should  only  affect  the 
processes  above;  this  interface  resynchronization  should  be 
invisible  to  both  the  process  which  interprets  IMP-to-Host 
messages  (it  will  be  resynchronized  by  the  IMP*to<^Host  type  10 
message)  and  to  any  user  software. 

Actually,  it  is  possible  to  share  a  single  Error  flop 
between  the  input  and  output  processes  by  implementing  Input 
Error  and  Output  Error  as  software  flags.  A  process  testing  for 
error  is  required  (e.g.,  a  mutual  exclusion  semaphore)  to 
guarantee  that  only  one  process  at  a  time  is  testing  and 
modifying  the  flags.  If  the  Error  flop  is  set,  the  process  must 
copy  it  into  the  other  process*  flag  before  clearing  the  flop  and 
its  own  flag. 
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B.3  Host  Ready  Line  Implementation 

When  the  Host  drops  and  raises  its  ready  line,  the  IMP 
behaves  in  a  fashion  symmetric  to  that  outlined  above.  Of 
course,  this  drop  indicates  that  the  state  of  the  Host's 
interface  driver,  as  well  as  the  current  incoming  and  outgoing 
messages,  are  likely  to  be  lost.  The  appropriate  action  is 
triggered  by  setting  the  Error  flop  or  flops  in  the  Host 
interface,  and  the  processes  specified  above  will  correctly 
resynchronize  message  flow  in  both  directions.  Of  course,  to 
guarantee  that  messages  are  not  flowing  across  the  interface 
while  the  Host  ready  line  is  undergoing  contact  bounce,  the  Host 
must  delay  transmission  until  its  ready  line  has  stabilized. 
This  may  be  done  in  two  ways: 

Hardware:  an  integrating  one-shot  driven  by  the  Host  ready 
line  flop  is  ANDed  with  There* s-Your-Host-Bit  and 
Ready-For-Next-IMP-Bi t  to  guarantee  that  message 
transfer  will  not  start  until  the  ready  flop  has 
been  on  for  1/2  second. 

Software:  the  initialization  program  executes  a  1/2  second 
wait  after  setting  the  Host  ready  flop  before 
permitting  input  or  output  to  begin. 
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B.4  Summary  of  Ready  Line  Controls 

The  following  summarizes  the  specification  of  the  Host’s 
Ready  Line  control: 

1.  The  special  Host  interface  contains  a  Host  ready  flop 
which  drives  a  relay  closure  in  the  Host  Ready  line. 
This  flop  is  set  and  cleared  under  program  control. 

2.  The  special  Host  interface  detects  the  IMF’s  ready 
signal  and  seta  a  program-readable  status  condition  (not 
an  "interrupt”  condition) . 

3.  The  special  Host  interface  contains  one  or  two  error 
flops  set  when  either  the  Host  Ready  flop  is  off  or  the 
IMP  ready  signal  is  off.  The  flop  (flops)  is  a 
program-readable  and  program-clearable  status  condition 
(but  not  an  interrupt  condition).  These  status  flops 
must  not  be  cleared  by  system  initialization. 

4.  If  hardware  stabilization  of  the  Host’s  Ready  line  is 
provided,  it  is  a  1/2  second  integrating  one-shot  driven 
by  the  Host  Ready  flop.  This  signal  is  AKDed  with 
There’ s-Your-Host-Bit  and  Ready-For-Next-IMP-Bit . 
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LOCAL  HOST  CONNECTION 
ELECTRICAL  CHARACTERISTICS 
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All  Host-IMP  logic  signals  (Data,  Ready-For-Next-Bit, 
There* s-Your-Bit,  Last  Bit)  are  unbalanced,  source-terminated 
lines  with  a  nominal  characteristic  impedance  of  68  ohms.  The 
line  is  terminated  at  the  driving  end  with  the  characteristic 
impedance.  The  receiver  is  ideally  an  open  circuit;  in  practice, 
it  is  a  single  TTL  gate.  In  this  scheme  a  voltage  step  of  half 
the  nominal  level  is  propagated  from  source  to  receiver.  At  the 
receiver,  it  is  reflected  by  the  high  impedance  termination, 
resulting  in  a  full  level  step  at  the  receiver  and  another  half 
level  step  propagating  back  to  the  source,  where  it  is  absorbed 
by  the  termination. 


Voltage  levels 

for 

drivers  and 

receivers  used  by  the  IM®  are 

given  below: 

Min 

Typ 

Max 

Pluribus 

'^OH 

4.1 

5.0 

'^OL 

0.07 

0.1 

''IH 

1.7 

2.0 

0.6 

0.9 
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316/516 

'^OH 

3.5 

4.5 

VoL 

0.2 

0.35 

1.55 

2.5 

1.1 

1.35 

The  IMP  will  properly  receive  5-volt  logic  signals;  however, 
signals  from  the  IMP  may  go  to  6  volts.  Therefore,  the  Host  must 
provide  a  voltage  divider,  if  these  signals  are  to  be  received  by 
normal  5-volt  logic,  to  prevent  destruction  of  the  receiving 
circuit. 
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APPENDIX  D 

DRIVER  RECEIVER  FOR  DISTANT  HOST 


Printed  with  permlaalon  of  Honeywell,  Inc. 

Computer  Control  Division,  Framingham,  Massachusetts 
Descriptions  and  schematic  diagrams  reflect  use  in  the  IMP. 
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INPUT  +A 
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fr)  OUTPUT 


INPUT  -A 
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0X)33/if 


input  ^A— J2 
input  -a— Ia 


CC-124  J 


•OUTPUT 


L  cc-'24  .J 


It  it 

II  19  13 


\»  CC-124  ,J 


Figure  D-1  Differentiel  Receiver  PAC  Hodel  CC-124 »  Schematic 
Diagram  and  Logic  Symbol.  (Shotm  at  connected  in  IMP) 
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<  D.1.3  Specifications 

i 

i 

Frequency  of  Operation:  DC  to  5  MC. 

Input:  Differential  signal,  0.1V  to  4.0V. 

Input  Impedance:  2.5K  (min.) 

Common  Mode  Rejection:  Greater  than  t2.5V 
Output  Drive  Capability:  8  unit  loads  and  70  pf  stray 

capacitance  each. 

Circuit  Delay:  30  nsec  (max.). 

Current  Requirements  (exclusive  of  terminators): 

♦6V:  60  ma  (max .) . 

-6V:  30  ma  (max.) . 

D.2  Differential  Line  Driver  PAC  Model  CC-125 

The  Differential  Line  Driver  PAC,  model  CC-125f  contains 
three  identical  and  independent  circuits.  Each  circuit  will 
switch  approximately  18  ma  into  a  balanced  load  when  a  standard 
u«PAC  logic  level  of  "1”  is  present  at  the  input.  When  the  input 
is  at  logic  ”0",  the  output  is  open  circuited.  The  schematic 
diagram  (Figure  D-2)  reflects  use  of  this  PAC  in  the  IMP.  Note 
that  the  circuit  has  been  modified  by  the  addition  of  externally 
(i.e.,  back  panel)  mounted  resistors. 
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D.2.1  Circuit  Function 

When  the  input  is  at  ground  or  logic  "0",  is  biased  "on". 
With  "on",  the  emitters  of  Qg  and  are  biased  "off",  and  the 
output  is  effectively  open-circuited. 

When  the  input  is  open  or  at  logic  "1",  is  turned  "off", 
which  causes  Q2  and  to  turn  on,  switching  approximately  18  ma 
into  the  output. 

D.2.2  Terminating  Network 

The  terminating  network  consists  of  resistors  R7-R10  as  well 
as  the  externally  mounted  resistors  R101  and  R102,  and  is 
designed  for  use  with  100  to  140  ohm,  balanced,  twisted-pair 
transmission  lines.  With  a  logic  "0"  applied  to  the  input  of  the 
transmitter,  the  terminating  network  establishes  a  1.0V 
differential  signal  on  the  transmission  line  pair.  When  a  logic 
"1"  is  applied  to  the  input  of  the  transmitter,  the  polarity  of 
the  1-volt  differential  signal  on  the  transmission  line  pair  will 


be  reversed. 
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D.2.3  Specifications 


Frequency  of  Operation:  DC  to  5  MC. 

Input  Loading:  1  unit  load  each. 

Output  Drive  Capability:  Approximately  18  ma  into  a 

balanced  load. 

Circuit  Delay:  15  nsec  (max.). 

Current  Requirements:  Exclusive  of  terminators 

♦6V:  90  ma  (max .) . 

-6V:  90  ma  (max.) . 

The  combination  of  the  internal  terminator  network  and  the 
externally  connected  resistors  will  draw  about  9  ma  each  when 
connected  to  ^67  and  -6V. 
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ASCII  CODES 

ASCII 

OTT  Hn  MNEMONIC  SYMBOL 


2B0 

89 

NUL 

^0 

291 

81 

SOH 

^A 

292 

82 

SIX 

tB 

293 

83 

ETX 

tc 

29M 

84 

EOT 

to 

205 

85 

ENQ 

tF 

296 

86 

ACK 

tF 

297 

87 

BEL 

to 

219 

88 

BS 

tH 

211 

89 

HT 

tl 

212 

8A 

LF 

tj 

213 

8B 

VT 

tK 

214 

8C 

FF 

tL 

215 

80 

CR 

tM 

216 

8E 

SO 

tH 

217 

8F 

SI 

to 

220 

90 

OLE 

tp 

221 

91 

0C1 

tQ 

222 

92 

0C2 

tR 
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ASCII 

OTT  hex  mnemonic  symbol 


247 

A7 

25i0 

A8 

( 

251 

A9 

) 

252 

AA 

a 

253 

ab 

♦ 

254 

AC 

f 

255 

AD 

- 

256 

AE 

• 

257 

AF 

/ 

26flr 

Bor 

0 

261 

B1 

1 

262 

B2 

2 

263 

B3 

3 

264 

B4 

4 

265 

B5 

5 

266 

B6 

6 

267 

B7 

7 

216 

B8 

8 

271 

B9 

9 

272 

BA 

• 

• 
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ASCII 

TJCT  hR  mnemonic  symbol 


317 

CF 

0 

32£l 

D0 

P 

321 

D1 

Q 

322 

02 

R 

323 

03 

S 

324 

04 

T 

325 

05 

U 

326 

06 

V 

327 

07 

W 

330 

08 

V 

A 

331 

09 

Y 

332 

OA 

Z 

333 

OB 

c 

334 

OC 

\ 

335 

OD 

] 

336 

OE 

A 

337 

OF 

340 

E0 

% 

341 

El 

a 

342 

E2 

b 
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ASCII 


KNEHONIC  SYMBOL 


RUBOUT 


The  IMP  uses  8-bit  ASCII  with  the  left-Bost  bit  set  to  one. 


f  «  control 


+•  -  shift  control  -  P 
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VERY  DISTANT  HOST  INTERFACE 


(OBSOLETE) 


APPENDIX 


1822 


Report  No.  1^22 


Bolt  Beranek  and  Newman  inc. 


APPENDIX  G 

IMP  POWER  WIRING  CONVENTION 
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1  Overview 

This  report  specifies  the  attachment  of  an  HDH  host  to  a  BBN 
Communications  Corporation  (BBNCC)  C/30  Packet  Switching  Node 
(IMP).  This  report  assumes  that  the  reader  is  familiar  with 
CCITT  Recommendation  X.25  and  FIPS  100/Fed.  Std.  1041.  For  the 
purposes  of  the  ensuing  discussion,  references  to  the  DCE  refer 
to  that  part  of  the  IMP  which  interfaces  with  the  host. 
References  to  the  DTE  refer  to  that  part  of  the  host  entity  which 
interfaces  with  the  IMP. 


The  HDH  interface  protocol  is  a  combination  of  protocol 
layers  Including  LAPB,  HDH  itself,  and  1822.  HDH  is  defined 
as  four  Independent  architectural  levels  that  fit  into  the  Open 
Systems  Interconnection  (OSI)  Reference  Model  in  the  following 
way: 


Level  1:  The  PHYSICAL  level  of  the  connection.  The 

physical,  electrical,  functional,  and  procedural 
characteristics  to  activate,  maintain,  and 

deactivate  the  physical  link  between  the  DTE  and 
the  DCE.  (See  J.2) 

Level  2:  The  LINK  level  of  the  connection.  The  link  access 
procedure  for  data  interchange  across  the  link 
between  the  DTE  and  the  DCE.  The  HDH  IMP  uses  the 
LAPB  subset  of  HDLC. 


Level  3:  The  PACKET  level  of  the  connection.  The  packet 
format  and  control  procedures  for  the  exchange  of 
packets  containing  control  information  and  user 
data  between  the  DTE  and  the  DCE  Is  provided  by 
the  HDH  protocol.  The  1822  protocol  provides 
procedures  for  the  exchange  of  these  packets 
between  bne  uic.  ana  a  remoie  DTE. 
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HDH  has  a  packet  mode  option  and  a  message  mode  option*  In 
the  packet  mode  option, data  from  several  LAPB  information  (I) 
frames  are  combined  to  form  one  1822  message*  In  the  message 
mode  option  the  entire  1822  message  is  held  in  one  LAPB  I  frame* 
A  diagram  of  an  HDH  frame  within  a  LAPB  I  frame  is  shown  in 
Figure  J-1 *  The  LAPB  subset  of  the  HDLC  protocol  is  specified  in 
the  CCITT  Recommendation  X.25  1980,  which  is  provided  in  Appendix 
K  of  this  document*  Section  3  of  this  appendix  provides  general 
information  about  the  BBN  C/30  LAPB  implementation  and  Appendix 
J*1  provides  notes,  organized  by  reference  to  the  CCITT  X*25 
document,  which  help  to  clarify  the  functional  link  level 
characteristics*  The  HDH  protocol  is  described  in  Section  4 
and  an  HDH  host  finite  state  machine  is  provided  in  Section  5* 
Diagrams  of  the  HDH  protocol  formats  are  shown  in  Figures  J-2  and 
J-3  • 


Each  1822  message  is  fragmented  into  one  or  more  LAPB 
frames*  Each  LAPB  frame  includes  2  octets  of  LAPB  header  and  2 
octets  of  HDH  header*  The  HDH  protocol  is  inserted  between  LAPB 
and  1822  to  act  as  an  access  protocol*  HDH's  functions  are  to 
segment  1822  messages  into  LAPB  frames,  rebuild  messages  from  the 
frames,  perform  line  quality  monitoring,  simulate  the  Kost-IMP 
ready  line  up/down  signalling  which  is  handled  by  hardware 
mechanisms  in  the  1822  hardware  interface,  and  operate  the 
loopback  and  reflect  modes*  Only  the  first  LAPB  frame  of  an  HDH 
message  contains  an  1822  leader.  The  rest  of  the  frames,  if 
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-HDH  HEADER 
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DATA  FRAME 


Figure  J-3  HDH  Message  Mode  Format 
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any«  contain  LAPB  and  HDH  headers  in  addition  to  1822  message 
data. 


1.1  Choosing  the  Correct  HDH  Interface 

The  choice  between  HDH  packet  mode  or  HDH  message  mode  is 
entirely  site  dependent;  therefore*  the  choice  is  left  up  to  the 
IMP  site  manager.  The  following  is  a  short  discussion  of  the 
factors  which  may  affect  the  decision. 

Message  mode  allows  for  rather  large  single  frame  messages , 
while  packet  mode  allows  large  messages  to  be  broken  up  into 
smaller  message  frames.  Hosts  using  message  mode  must  therefore 
provide  enough  ready  buffer  space  for  the  largest  possible 
messages  (1021  octets  excluding  the  LAPS  header).  This  can  be 
done  with  large  buffers  or.  if  the  host  has  a  scatter/gather 
DMA  channel,  through  buffer  chains.  Packet  mode  allows  the  host 
to  divide  its  memory  resources  into  smaller  buffers  because 
messages  are  broken  into  a  number  of  LAPB  frames  whose  maximum 
size  is  limited  to  128  octets  (excludinr  the  LAPB  header).  The 
Level  2  (LAPB)  window  of  seven  might  limit  throughput  more  with 
shorter  Packet  Mode  packets  than  with  long  Mt^sage  Mode  packets. 
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1 .2  Hardware  Requirements 

This  report  specifies  the  interface  presented  by  a  BBN 
Communications  Corporation  C/30  Processor!  together  with  specific 
commercial  software  products.  DTE  attachment  requires  the  C/30 
MSYNC  I/O  interface  board.  To  support  the  HDH  interface 
described  in  this  report,  the  C/30  must  be  configured  with  at 
least  64  thousand  (64K)  words  of  main  memory. 


1.3  Summary  of  Features 

The  C/30  IHP  supports  three  physical  interface  standards* 
RS-232C,  RS-449,  and  V.35t  et  clock  rates  from  1.2  to  64  kilobits 
per  second  (Kb/s).  Physical  line  status  is  sampled  using 
incoming  status  interchange  circuits. 

The  C/30  IHP  link  level  interface  supports  both  LAP  and  LAPB 
procedures.  Link  level  status  monitoring  during  LAPB  operation 
is  accomplished  using  a  transparent  idle*link  polling  mechanism. 
DCE  li.k  level  parameters  are  configurable. 

The  C/30  HDH  packet  level  Interface  supports  either  Packet 
Mode  cr  Message  Mode  transfer  formats. 
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2  Physical  Level  Specifications 

The  C/30  HDH  IMP  physical  level  specification  is  in 
conformance  with  FIPS  100/Fed.  Std.  1041  and  CCITT 
Recommendation  X.25.  This  section  presents  additional 
information. 

An  HDH  DTE  attached  to  a  C/30  HDH  IMP  may  be  collocated  with 
the  IMP  or  may  be  connected  to  it  via  an  access  line.  In  all 
cases  the  DTE  presents  a  physical  DTE  interface;  the  network 
administration  must  supply  the  matching  DCE  interface.  By 
appropriate  choice  of  modem  or  modem-like  hardware,  an 
administration  could  offer  up  to  four  physical  level  interfaces: 
RS-232-C  (CCITT  V.28) ,  RS-449,  both  balanced  and  unbalanced 
(CCITT  V.11  and  V.10,  respectively;  also  MIL-188-114  balanced  and 
unbalanced),  and  CCITT  V.35.  Appendix  J.2  of  this  document 
describes  in  detail  the  choices  of  physical  interface  that  might 
be  made  available  to  a  host  DTE  attached  to  a  C/30  HDH  IMP  and 
the  specifications  for  each  type  of  interface.  Table  J.1 
summarizes  the  physical  interfaces  available  at  each  data  rate 
supported  by  the  C/30  HDH  DCE. 

An  HDH  DTE  may  implement  more  than  one  signalling  rate.  At 
each  signalling  rate  implemented,  the  DTE  must  offer  at  least  one 
of  the  physical  interface  options  listed  as  "A"  (available)  for 
that  rate  in  Table  J.1.  DTE  implementors  are  encouraged  to  offer 
the  widest  variety  of  signalling  rates  and  physical  interfaces 
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3  Link  Level  Procedures 

C/30  HDH  link  level  procedures  are  as  specified  by  CCITT 
Recommendation  X.25  (see  Appendix  K)  and  FIPS  100/Fed.  Std.  1041. 
This  section  presents  additional  information. 


3.1  Link  Level  Parameters  and  Options 


1.  The  default  value  of  K,  the  maximum  number  of 

sequentially  numbered  I  frames  that  the  DCE  will  have 

outstanding  (unacknowledged)  at  any  given  time,  is 
seven.  The  Administration  may  configure  a  C/30  HDH  DCE 
to  have  an  optional  value  of  K  from  one  to  six. 

2.  The  default  value  of  N2,  the  maximum  number  of 

transmissions  and  retransmissions  of  a  frame  by  the  DCE 
following  the  expiration  of  the  T1  timer,  is  twenty. 
The  Administration  may  configure  a  C/30  HDH  DCE  to  have 
an  optional  value  of  N2  from  one  to  200. 

3.  The  optional  32-bit  Frame  Checking  Sequence  (FCS)  is  not 
supported. 


3.2  Timer  T1  and  Parameter  T2 


The  period  of  the  timer  T1  used  by  the  C/30  HDH  DCE  reflects 
assumptions  about  the  processing  speed  of  the  DTE.  The  DCE 
assumes  that  parameter  T2,  the  response  latency  of  the  DTE  to  a 
frame  from  the  DCE,  is  no  greater  than  1/2  second.  Likewise,  the 
DCE  guarantees  that  its  parameter  T2.  the  latency  in  responding 
to  frames  from  the  DTE.  is  1/2  second  for  signalling  rates  of 

19.2  Kb/s  or  slower,  and  1/4  second  for  faster  links. 
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T1  may  be  computed  to  be  4X  +  T2,  based  on  the  assumptions 
that  the  link  propagation  time  is  negligible,  the  worst-case 
frame  transmission  time  is  X,  and  that  timer  T1  is  started  when  a 
frame  is  scheduled  for  output,  that  each  frame  is  scheduled  just 
as  transmission  of  the  previous  frame  starts,  that  frames  are  not 
aborted,  and  that  each  frame  and  its  predecessor  are  of  maximum 
length  N1  =  8184  bits  for  Message  Mode  or  N1  =  1040  for  Packet 
Mode. 


As  an  example,  for  a  signalling  rate  of  9.6  Kb/s,  this 
yields  X  =  .82  sec  (for  Message  Mode).  If  T2  is  .5  sec.,  the 
total  time  for  the  DTE  to  respond  in  the  worst  case  should  be  3.8 
seconds.  In  fact,  the  DCE  uses  a  T1  timer  value  of  4  seconds  for 
a  link  speed  of  9.6  Kb/s. 

In  no  case  does  the  DCE  use  a  value  for  T1  smaller  than  3 
seconds.  This  means  that,  for  faster  links,  the  DTE’s  T2 
parameter  may  be  lengthened  because  the  X  term  in  the  above 
formula  is  smaller.  For  links  of  19.2  Kb/s  or  faster,  DTEs  are 
expected  to  satisfy  latency  requirements  that  all^ow  the  DCE  to 
use  the  formula  4X  ♦  T2  <  3  seconds. 

The  DTE  may  choose  any  value  for  T1  that  is  compatible  with 
the  DCE’s  T2  parameter  values.  The  value  of  T1  used  by  the  DTE 
may  always  be  set  longer  than  the  formula  indicates,  with  the 
result  that  recovery  from  certain  types  of  link  errors  will  be 
slower.  However,  the  DCE’s  parameter  T2  cannot  be  reduced,  so 
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4  Packet  Level  Procedures 

The  packet  level  of  the  HDH  interface  is  implemented  in  two 
protocol  layers;  HDH  which  is  described  below,  and  1822  host/IMP 
protocol  which  is  described  in  BBN  Report  1822. 

4.1  The  HDH  Protocol 

The  HDH  protocol  is  implemented  on  IMPs  to  support  the 
connection  of  hosts  to  the  IMP  using  LAPB  at  the  link  level,  and 
the  Host  IMP  Protocol  (1822)  at  the  network  level. 

The  interface  inserts  the  HDH  transmission  protocol 
underneath  the  standard  1822  protocol i  while  using  1-APB  as  the 
link  level  protocol.  Therefore,  each  LAPB  frame  carries  a  two- 
octet  HDH  header  plus  an  1822  protocol  message.  In  order  to 
accommodate  both  present  and  future  requirements,  the  HDH 
protocol  has  two  modes  as  shown  in  Figures  J-2  and  J-3.  One  mode 
is  called  packet  mode;  it  requires  that  the  information  part  of 
the  LAPB  frame  not  exceed  128  octets  (126*data  2  for  HDH 
header),  and  that  the  1822  leader  be  sent  in  a  separate  frame. 
In  this  mode,  the  host  and  IMP  explicitly  break  up  messages  into 
packets.  The  other  mode,  called  message  mode,  permits  the  entire 
message  (up  to  1007  data  octets,  plus  leader)  to  be  sent  in  a 
single  LAPB  frame.  The  mode  used  by  a  particular  IMP  interface 
is  set  at  subscription  time,  but  may  be  changed  by  requesting  a 
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new  configuration  from  the  network  operations  center.  The  mode 
cannot  be  set  dynamically  via  negotiations  between  the  host  and 
the  IMP. 

The  HDH  protocol  is  required  at  the  local  host-IMP 
connection  in  order  to  segment  messages  into  packets,  rebuild 
messages  from  packets,  perform  line  quality  monitoring,  simulate 
the  Host-IMP  ready  line  up/down  signalling,  and  operate  the  IMP 
loopback  and  reflect  modes.  The  remainder  of  this  section 
describes  the  HDH  protocol.  Whereas  the  IMP  will  implement  the 
entire  protocol,  there  are  a  few  elements  need  not  be  implemented 
by  the  host,  and  those  will  be  so  noted. 


4.1.1  HDH  Data  Messages 

The  host  and  IMP  send  each  other  LAPB  frames  using  the 
formats  illustrated  in  Figures  J-1,  J-2  and  J-3t  Each  LAPB 
frame,  in  addition  to  the  LAPB  address  and  control 
octets,  contains  a  16-bit  HDH  header  which  is  shown  in  Figure  J- 
4.  The  header  fields  are  described  below.  HDH  Control  Frames 
are  shown  in  Figure  J-5,  and  are  described  in  section  4.1.2  . 
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LAPB 


HDH  CONTROL  HEADER 


Figure  J-5  HDH  Control  Frame  -  Packet  or  Message  Mode 
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Bit  15  -  Control  bit 

The  high  order  bit  of  the  HDH  header  distinguishes  HDH 
control  franes  (to  be  discussed  later)  from  data  frames. 

Bit  14  -  Sequence  Break  (SEQ)  bit 

This  bit,  when  set  to  one*  indicates  a  sequence  break  in 
the  frame  stream  between  the  previous  frame  and  the 
current  one  (see  description  below). 

Bit  13  -  Host/IMP  bit 

This  bit  indicates  if  the  frame  was  host  or  IMP 

originated.  A  zero  indicates  a  host  originated  frame  and 
a  one  indicates  an  IMP  originated  frame. 

Bit  12  -  Start  of  Message  (SOM) 

This  bit,  when  set.  indicates  that  this  frame  is  the 

first  frame  in  a  message. 

Bit  11  -  End  of  Message  (EOM) 

This  bit,  when  set,  indicates  that  this  frame  is  the 

last  frame  in  a  message. 

Bit  10  .  Reflect  Mode  (REF)  bit 

This  bit  indicates  that  the  current  frame  sent  by  the  IMP 
to  the  host  must  be  looped  back  to  the  IMP  unchanged. 
Only  the  IMP  is  allowed  to  set  this  bit  (see  below). 

Bits  9*0  Octet  Count 

This  field  contains  a  count  of  octets  in  the  rest  of 
the  frame  (exclusive  of  the  LAPB  and  HDH  headers). 


The  sequence  break  bit  (SEQ)  is  used  by  the  host  or  IMP  to 
signal  to  the  other  side  that  a  discontinuity  has  occurred  in  the 
message  stream.  When  either  side  receives  an  HDH  frame  with  the 
SEQ  bit  set.  it  should  discard  any  accumulated  frames  of  messages 


up  to  the  last  EOM  (i.e.  the  last  complete  message)  and  continue 
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to  discard  new  frames  until  the  next  start  of  message 
(SOM)  is  received.  This  has  two  practical  uses  in  the  HDH 

environment: 

1.  The  IMP  will  send  an  HDH  sequence  break  when  it  first 

brings  the  HDH  level  up  to  cause  the  host  to  discard  any 
old  message  frames  which  might  remain  on  the  host's 
input  queues.  The  host  may  send  an  HDH  sequence  break  at 
this  time,  but  it  is  not  necessary  since  the  IMP  flushes 
its  queues  when  the  HDH  level  is  taken  down.  Line  Just 
up  is  the  only  case  where  an  HDH  sequence  break  has 

meaning  in  message  mode  HDH. 

2.  In  packet  mode»  the  HDH  sequence  break  is  the  mechanism 

by  which  one  end  can  inform  the  other  end  that  it 

detected  a  potential  discontinuity  in  the  message  it  was 
sending.  For  example,  an  internal  reset  in  the  host 
might  cause  such  a  data  loss.  Ideally,  the  host  should 
send  an  HDH  sequence  break  followed  by  a  retransmission 
of  the  entire  packet  mode  message  starting  with  the  SOM 
packet.  If  the  host  cannot  keep  a  copy  of  the  complete 
packet  mode  message  due  to  buffer  space  limitations,  it 
should  Just  send  the  HDH  sequence  break  followed  by  the 
next  complete  packet  mode  message.  Higher  layers  must 
detect  the  data  loss  and  cause  retransmission  in  this 
case.  It  is  Important  to  send  HDH  sequence  breaks  only 
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when  the  desired  recovery  can  be  achieved. 

The  host/IMP  bit  is  used  by  the  IMP  to  confirm  the  loopback 
condition  from  the  IMP  to  itself.  The  host  should  always  send 
its  frames  with  this  bit  zero,  and  the  IMP  with  the  bit  set  to 
one.  The  host  need  not  implement  a  loopback  mode,  but  it  is 
recommended  that  in  any  case  this  bit  be  examined  in  order 
to  detect  possible  inadvertent  loopback  conditions.  The 
CCITT  X.25  specification  (Appendix  K)  does  not  address  the  issue 
of  a  functional  loopback  condition,  and  implies  looped  frames 
will  always  be  discarded.  In  practice,  however,  it  is  possible 
to  have  a  functional  loopback  by  exchanging  the  LAPS  addresses  A 
and  B  on  output,  and  this  practice  may  be  observed  by 
various  LAPB  implementations  (as  it  is  in  the  IMP). 

In  packet  mode,  the  SOM  and  EOM  bits  are  used  to  delimit 
messages.  In  an  1822  type  0  message  of  zero  length,  or  in  a 
non-type  0  (1822  control,  such  as  RFNM),  both  bits  are  turned  on 
and  the  leader  frame  constitutes  the  entire  message. 
Otherwise,  only  the  SOM  bit  is  turned  on  in  the  leader,  neither 
bit  is  turned  on  in  middle  packets,  and  EOM  is  turned  on  in  the 
last  packet.  The  IMP  discards  frames  which  violate  these  rules. 
If  violations  occur. an  1822  error  in  data  message  will  be 
returned  to  the  host. 

In  message  mode,  both  SOM  and  EOM  are  turned  on  in  all 
frames,  and  the  leader  and  data  portions  of  the  message  are 
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included  continuously  in  the  same  frame.  The  IMP  discards  frames 
which  violate  this  rule.  If  violations  occur,  an  1822  error  in 
data  message  will  be  returned  to  the  host. 

The  reflect  mode  (REF)  bit  indicates  that  the  IMP  expects 
the  host  to  return  everything  it  receives  UNCHANGED.  This  is  an 
important  diagnostic  tool  which  aids  the  network  operations 
center  in  debugging  problems  on  HDH  links.  Only  the  IMP  is 
allowed  to  set  this  bit.  If  the  host  implementor  requires  a 
loopback  to  the  host,  this  can  be  implemented  by  sending  HDH 
packets  with  1822  leaders  addressed  to  the  the  sending  host.  The 
IMP  will  simply  route  these  packets  right  back  to  the  host. 

The  octet  count  field  indicates  the  number  of  valid  octets 
in  the  remainder  of  the  frame.  This  field  must  always  be  filled 
in,  and  may  Indicate  fewer  or  the  same  number  of  octets 
as  the  physical  frame  contains.  This  is  to  provide  for  host 
word  si.?es  that  may  not  always  align  with  the  desired 
packet  size. 


In  packet  mode,  the  first  LAPB  frame  contains  only  the  1822 
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octet  count  must  be  at  least  10  (for  non-type  0  messages) »  and 
may  oe  any  number  up  to  and  Including  1019*  An  octet  count 
larger  than  the  amount  in  the  physical  frame  or  a  count  which 
violates  the  aoove  maximum  HDH  frame  length  rules  is  considered 
a  protocol  violation  and  the  IMP  will  discard  the  illegal  frame 
and  an  1822  error  in  data  message  will  be  returned  to  the  host. 


4.1.2  HDH  Control  Messages 


HDH  control  frames,  shown  in  Figures  J-4  and  J-5»  are 
distinguished  by  having  the  high-order  bit  of  the  HDH  header  set 
to  1 ,  and  are  used  for  measuring  the  quality  of  the  packet  level 
and  determining  its  up/down  status.  HDH  control  frames  contain 
no  additional  octets  beyond  the  HDH  header. In  the  following 
discussion,  control  frames  sent  by  the  IMP  are  called  "Helloes 
and  control  frames  sent  by  the  host  are  called  "I-heard-you"s. 
The  following  is  a  description  of  the  fields  in  an  HDH  control 
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-  Control  bit 

The  high  order  bit  of  the  HDH  header  distinguishes  HDH 
control  frames  (bit  set  to  1)  from  data  frames. 

-  Sequence  Break  (SEQ)  bit 

This  bit,  when  set,  indicates  a  sequence  break  in  the 
frame  stream  between  the  previous  frame  and  the  current 
one. 

-  Host/IMP  bit 

This  bit  indicates  if  the  frame  was  host  or  IMP 
originated.  A  zero  indicates  a  host  originated  frame  and 
a  one  indicates  an  IMP  originated  frame. 

-  Line  Status  (LIN)  bit 

This  bit,  when  set,  indicates  the  HDH  level  between  the 
host  and  IMP  Is  up  (see  description  below). 

-  Link  Quality  Poor  (LQP)  bit 

When  this  bit  is  set  to  one.  it  indicates  that  the  IMP 
has  determined  that  the  quality  of  the  LAPB  link  level  is 
below  the  "acceptable  quality"  threshold  configured  for 
this  host  link.  This  bit  may  be  set  by  the  IMP  before  the 
link  is  so  bad  that  the  link  cannot  transfer  data  at  all 
(see  description  below), 

-  Reflect  Mode  (REF)  bit 

This  bit  indicates  that  the  current  frame  sent  by  the  IMP 
to  the  host  must  be  looped  back  to  the  IMP.  Only  the  IMP 
is  allowed  to  set  this  bit  under  the  current  HDH  protocol 
specification. 

-0  -  Line  Down  Counter 

This  field  contains  the  control  message  timer  value  for 
the  IMP/Host  line.  The  host  should  declare  the  HDH  level 
down  if  it  has  not  received  a  control  message  ("hello") 
from  the  IMP  before  the  indicated  time  period  lapses. 
The  timer  is  expressed  in  units  of  one  second  and  can 
have  reset  values  ranging  from  3  to  1023  (see  description 
below) . 
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In  addition  to  the  previously  described  sequence  break 
(SEQ),  reflect  mode  (REF),  and  host/IMP  bits,  the  HDH  header 
contains  a  link  quality  poor  (LQP)  bit,  a  HDH  level  up/down  bit, 
and  a  line  down  timer  parameter  value,  all  of  which  are  described 
below.  The  control  frames  are  used  by  the  algorithm  described 
in  4. 1.2.1  to  decide  when  the  connection  between  the  host  and  the 
IMP  is  dead  or  alive. 

The  link  quality  poor  (LQP)  bit, when  set  to  one,  indicates 
that  the  IMP  has  determined  that  the  quality  of  the  LAPB  link 
level  is  below  the  "acceptable  quality"  threshold  configured  for 
this  host  link.  This  bit  may  be  set  by  the  IMP  before  the  link 
is  so  bad  that  the  HDH  level  is  declared  down  by  the  IMP.  Only 
the  IMP  sets  LQP.  For  singly  homed  hosts,  LQP  being  set  should 
cause  a  message  to  be  sent  to  the  operator  so  that  the  line 
situation  is  identified  as  a  possible  reason  for  poor  throughput. 
For  dually  homed  hosts,  LQP  being  set  should  cause  the  host  to 
try  its  other  HDH  line.  The  host  should  avoid  switching  back  and 
forth  if  the  alternate  HDH  line  has  the  LQP  bit  s^t  as  well. 

4. 1,2,1  HDH  Level  Up/Down  Algorithm 

HDH  requires  that  that  a  Master/Slave  relationship  exist 
between  the  IMP  and  the  host  so  that  the  HDH  level  up/down 
protocol  can  work  correctly.  Periodically,  the  IMP  sends  a 
control  frame,  called  a  "hello"  message,  to  the  host.  Since  the 
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frame  is  sent  by  the  IMP,  the  host/IMP  bit  is  one.  The  host 
should  respond  immediately  to  this  frame  by  changing  the  host/IMP 
bit  to  zero,  updating  the  LIN  bit  and  returning  the  frame  to  the 
IMP.  The  host's  response  is  called  an  "I-heard-you".  The  host 
cannot  originate  control  frames;  it  can  only  respond  to  ''hello”s 
with  "I-heard-you"s.  Only  the  IMP  can  set  the  LIN  bit  and  declare 
the  HDH  level  up.  The  LIN  bit  is  the  "virtual  IMP  ready  line" 
that  HDH  provides  to  replace  the  Host/IMP  hardware  ready  line. 
The  LIN  bit  the  IMP  sends  is  the  logical  AND  of  the  state  of  the 
IMP'S  ready  line  and  the  state  of  the  HDH  link  to  the  host.  The 
LIN  bit  the  host  sends  is  NOT  the  equivilent  of  a  "virtual  host 
ready  line"  because  a  host  cannot  set  the  LIN  bit  in  an  "I- 
heard-you"  to  one  if  the  IMP  has  not  set  it  to  one  in  the  last 
"Hello"  received.  The  host  may  take  the  HDH  level  down  at  any 
time  by  setting  the  LIN  bit  in  a  "I-heard-you"  to  zero.  Control 
frames  may  be  freely  intermixed  with  data  packet  frames, 
including  between  packets  of  the  same  message. 

The  IMP  expects  to  receive  the  I-heard-you  for  its 
hello  frame  before  it  goes  to  send  the  next  hello  frame  or 
within  2  seconds,  whichever  is  sooner,  and  if  it  does  not,  it 
records  a  miss.  If  more  than  KH  misses  occur  within  NH  tries, 
the  IMP  declares  the  HDH  connection  down.  This  condition  is 
called  HDH  level  down.  No  data  is  sent  on  the  HDH  connection 
while  the  HDH  level  is  down. 
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The  IMP  also  performs  a  link  quality  test  for  LAPB  hosts.  A 
count  of  the  number  of  level  2  frames  that  were  retransmitted  is 
divided  by  the  total  number  of  level  2  frames  sent.  If  this 
number  is  lower  than  a  configurable  parameter  called  the  "link 
useable  threshold",  the  HDH  level  is  declared  down.  Thus  HDH 
provides  tests  of  both  the  packet  level  and  link  level  quality  on 
a  periodic  basis  to  provide  the  maximum  amount  of  information 
about  the  host  connection. 

While  the  HDH  level  is  down,  the  IMP  continues  to  send  hello 
control  frames  and  the  host  responds  to  those  it  receives.  The 
IMP  will  declare  the  HDH  level  up  if  it  receives  MH  responses  in 
a  row  with  no  intervening  misses  AND  the  level  2  quality  is 
above  the  "link  useable  threshold".  The  host  must  obey  the 
declarations  of  the  IMP,  taking  the  HDH  level  down  or  up 
as  instructed  by  the  setting  of  the  HDH  level  up/down 
(LIN)  bit  in  the  hello  frame.  In  particular,  the  host  should  not 
send  data  on  the  line  while  hello  frames  indicate  that  the 
HDH  level  is  down. 

While  the  HDH  level  is  up  the  host  should  also  maintain  a 
"control  message  timer",  which  is  set  to  the  value  conveyed  in 
the  moat  recent  "line  down  count"  every  time  the  host 
receives  a  hello  control  frame  from  the  IMP.  If  the  timer 
ever  expires,  the  host  should  consider  the  HDH  level  down.  In 
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the  line  has  broken  so  completely  that  control  frames  are  not 
received  at  all  from  the  IMP.  Since  the  value  of  the  control 
message  timer  depends  on  the  line  speed,  and  since  the  host  may 
not  be  aware  of  the  line  speed,  the  reset  value  for  the  timer  is 
communicated  to  the  host  in  the  control  frames  sent  by  the  IMP. 
The  timer  is  expressed  in  units  of  one  second  and  can  have  reset 
values  ranging  from  3  to  1023. 

The  host  may  take  the  HDH  level  down  (turn  off  the  LIN  bit 
in  the  I-heard-you)  for  any  reason. 

Typical  values  for  the  IMP*s  parameters  in  the  packet 
level  protocol  are  KH=4,  NHs20,  and  MHslO.  The  interval  for 
sending  hello  control  frames  will  vary  depending  on  the  speed  of 
the  line.  Typically,  it  is  between  3*2  and  6.4  seconds.  Hence, 
it  may  take  as  long  as  a  minute  for  an  HDH  host  to  come  up. 
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5  HDH  Host  Finite  State  Machine 

The  HDH  protocol  has  two  states  in  message  mode  and  three 
states  in  packet  mode.  The  message  mode  states  are  the  HDH 
Level  Up  State  and  the  HDH  Level  Down  State.  The  packet  mode 
state  machine  has  two  HDH  level  up  states,  the  HDH  Level  Up 
Start  of  Message  State  and  the  HDH  Level  Up  Middle  of  Message 
State,  in  addition  to  the  HDH  Level  Down  State.  The  following 
is  a  summary  of  possible  actions  taken  by  the  host  in  response 
to  HDH  inputs  from  the  IMP  in  the  various  states. 


5.1  HDH  Message  Mode 


5.1.1  HDH  Level  Down  State 


Input  from  IMP:  Control  message.  The  host  responds  with  a 
control  message.  Additional  action  taken  is  based  on  the 
incoming  control  message  header  bits  as  follows: 


Sequence  break  bit  -  Flush  queues  if  LIN  bit  is  set  to 
one. 

Host/IMP  bit  off  -  Error,  message  is  discarded. 

Host/IMP  bit  on  -  Correct,  no  action  needed. 

LIN  bit  off  -  Stay  in  the  HDH  Level  Down  State. 

LIN  bit  on  -  Go  to  HDH  Level  Up  State. 

Reflect  bit  off  -  No  action  needed. 

Reflect  bit  on  -  This  frame  must  be  looped  back  to  the 
IMP.  No  other  control  frame  is  sent  by  the  host. 

Line  Down  Count  Field  -  Set  the  control  message  timer 
to  the  value  in  this  field. 
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Input  from  IMP:  A  data  message.  The  host*s  response  is 
based  on  the  incoming  data  message  HDH  header  bits  as 
follows: 

Sequence  Break  bit  «-  Ignored. 

Host/IMP  bit  off  -  Error,  message  is  discarded. 

Host/IMP  bit  on  -  Correct,  no  action  needed. 

SOM  and  EOM  on  -  Ignored  in  the  HDH  Level  Down  State. 

Reflect  bit  off  -  No  action  needed. 

Reflect  bit  on  -  This  frame  must  be  looped  back  to  the 
IMP  unchanged.  No  action  is  needed. 

5.1.2  HDH  Level  Up  State 

Input  from  IMP:  Control  message.  The  host  responds  with  a 
control  message.  Additional  action  is  based  on  the 
incoming  control  message  HDH  header  bits  as  follows: 

Sequence  Break  bit  -  Ignored. 

Host/IMP  bit  off  -  Error,  message  is  discarded. 

Host/IMP  bit  on  -  Correct,  no  action  needed. 

LIN  bit  off  -  Go  to  the  HDH  Level  Down  State  and 
stop  processing  incoming  data  messages. 

LIN  bit  on  -  No  action  needed. 

Reflect  bit  off  -  No  action  needed. 

Reflect  bit  on  -  This  frame  must  be  looped  back  to  the 
IMP  unchanged.  No  other  control  frame  is  sent  by  the 
host. 

Line  Down  Count  Field  -  Set  the  control  message 
timer  to  the  value  in  this  field. 
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Input  from  IMP:  Data  message.  Action  taken  is  based  on 
the  incoming  data  message  HDH  header  bits  as  follows: 

Sequence  Break  bit  -  Ignored. 

Host/IMP  bit  on  -  Error,  message  is  discarded. 

Host/IMP  bit  on  -  Correct,  no  action  needed. 

SOM  or  EOM  off  -  Error,  message  is  discarded. 

SOM  and  EOM  on  -  Correct,  process  data. 

Reflect  bit  off  -  No  action  needed. 

Reflect  bit  on  -  This  frame  must  be  looped  back  to  the 
IMP  unchanged.  No  further  action  needed. 


5.2  HDH  Packet  Mode 
5.2.1  HDH  Level  Down  State 


Input  from  IMP:  Control  message.  The  host  responds  with 
a  control  message.  Additional  action  is  based  on  the 
control  bits  in  the  incoming  control  message  as  follows: 


Sequence  Break  bit  -  Flush  queues  if  LIN  is  set  in  this 
control  packet.  If  LIN  not  set,  ignore. 

Host/IMP  bit  off  -  Error,  message  is  discarded. 

Host/IMP  bit  on  -  Correct,  no  action  needed. 

LIN  bit  off  •  Stay  in  the  HDH  Level  Down  State. 

LIN  bit  on  -  Go  to  HDH  Level  Up  Start  of  Message  State. 

Reflect  bit  off  -  No  action  needed. 

Reflect  bit  on  •  This  frame  must  be  looped  back  to  the 
IMP  unchanged  in  addition  to  any  other  processing 
which  may  be  needed.  No  other  control  frame  is  sent  by 
the  host. 

Line  Down  Count  Field  -  Set  the  control  message 
timer  to  the  value  in  this  field. 
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Input  from  IMP:  A  data  message.  The  host  response  is 
based  on  the  HDH  header  bits  of  the  incoming  data  message 
as  follows: 

Sequence  Break  bit  -  Ignored  in  the  HDH  Level  Down 
S ta  te . 

Host/IMP  bit  off  -  Error,  message  is  discarded. 

Host/IMP  bit  on  -  Correct,  no  action  needed. 

SOM  and  EOM  -  Ignored  in  the  HDH  Level  Down  State. 

Reflect  bit  off  -  No  action  needed. 

Reflect  bit  on  -  This  frame  must  be  looped  back  to  the 
IMP  unchanged.  No  further  action  needed. 


5.2.2  HDH  Level  Up  Start  of  Message  State 


Input  from  IMP:  Control  message.  The  host  responds  with  a 
control  message.  Additional  action  taken  is  based  on  the 
incoming  control  message  HDH  Header  bits  as  follows: 


Sequence  Break  -  Ignored  since  we  are  in  the  HDH 
Level  up  Start  of  Message  State  and  the  next  data  frame 
must  be  a  Start  of  Message  frame. 

Host/IMP  bit  on  -  Error,  message  is  discarded. 

LIN  bit  off  -  Go  to  HDH  Level  Down  State  and 
stop  processing  incoming  data  messages. 

LIN  bit  on  -  No  action  is  taken. 

Reflect  bit  off  -  No  action  needed. 

Reflect  bit  on  -  This  frame  must  be  looped  back  to  the 
IMP  unchanged.  No  other  control  frame  is  sent  by  the 
host. 

Line  Down  Count  Field  -  Set  the  control  message  timer 
the  value  in  this  field. 
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Input  from  IMP:  A  data  message.  The  host  response  is 
based  on  the  HDH  header  bits  of  the  incoming  data  message 
as  follows: 


Sequence  Break  bit  -  Ignored  in  HDH  Level  Up  Start 
of  Message  State  the  next  data  frame  should  be  the 
start  of  a  new  message. 

Host/IMP  bit  off  -  Error,  message  is  discarded. 

Host/IMP  bit  on  -  Correct,  no  action  needed. 

SOM  bit  on,  EOM  bit  off  -  Accept  frame  for  processing 
and  go  to  HDH  Level  Up  Middle  of  Message  State. 

SOM  bit  off  -  Error,  discard  incoming  frame. 

SOM  and  EOM  bit  on  -  This  is  a  single  frame  message. 
Process  message  and  stay  in  HDH  Level  Up  Start  of 
Message  State. 

Reflect  bit  off  -  No  action  needed. 

Reflect  bit  on  •  This  frame  must  be  looped  back  to  the 
IMP  unchanged  in  addition  to  any  further  processing. 


5.2.3  HDH  Level  Up  Middle  of  Message  State 

Input  from  IMP:  Control  message.  The  host  responds  with  a 
control  message.  Additional  action  taken^ is  based  on  the 
incoming  control  message  HDH  header  bits  as  follows: 


Sequence  Break  (SEQ)  bit  on  -  Discard  all  previous 
frames  in  this  message,  go  to  HDH  Level  Up  Start  of 
Message  State. 

Host/IMP  bit  on  -  Correct,  no  action  needed. 

Host/IMP  bit  off  -  Error,  message  is  discarded. 

LIN  bit  off  -  Go  to  HDH  Level  Down  state,  stop 
processing  incoming  data  messages,  and  discard  all 
previous  frames. 
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LIN  bit  on  -  No  action  is  taken. 

Reflect  bit  off  -  No  action  needed. 

Reflect  bit  on  -  This  frame  must  be  looped  back  to  the 
IMP  unchanged.  No  other  control  frame  is  sent  by  host. 

Line  Down  Count  Field  -  Set  the  control  message  timer 
to  the  value  in  this  field. 


Input  from  IMP:  A  data  message.  The  host  response  is 
based  on  the  HDH  header  bits  of  the  incoming  data  message 
as  follows: 


Sequence  Break  (SEQ)  bit  on  -  Discard  all  previous 
frames  in  this  message,  go  to  HDH  Level  Up  Start  of 
Message  State.  If  this  frame  has  the  SOM  bit  set. 
treat  it  as  the  first  frame  and  go  to  HDH  Level  Up 
Middle  of  Message  State. 

Host/IMP  bit  off  -  Error,  message  is  discarded. 

Host/IMP  bit  on  •  Correct,  no  action  needed. 

SOM  on  -  Error,  discard  all  previous  frames  in  this 
message,  treat  the  new  frame  as  a  start  of  message,  and 
stay  in  the  HDH  Level  Up  Middle  of  Message  State. 

EOM  on  -  The  message  is  now  complete,  process  it  and.  go 
to  the  HDH  Level  Up  Start  of  Message  State. 

SOM  and  EOM  bit  off  -  This  is  a  valid  packet  mode 
middle  packet,  process  it  and  wait  for  next  data 
packet. 

Reflect  bit  off  -  No  action  needed. 

Reflect  bit  on  -  This  frame  must  be  looped  back  to  the 
IMP  unchanged.  No  further  action  needed. 
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APPENDIX  J.1:  Alignment  to  Recommendation  X.25 

This  appendix  contains  notes  which  help  to  clarify  the 
functional  link  level  characteristics  of  the  C/30  HDH  DCE.  It  is 
organized  by  reference  to  the  relevant  section  of  the  CCITT 
Recommendation  X.25,  "Interface  Between  Data  Terminal  Equipment 
(DTE)  and  Data  Circuit-Terminating  Equipment  (DCE)  for  Terminals 
Operating  in  the  Packet  Mode  on  Public  Data  Networks," 
International  Telegraph  and  Telephone  Consultative  Committee 
YELLOW  BOOK,  Vol.  VIII. 2,  Geneva,  1981.  Numbers  in  square 
brackets  indicate  sections  of  that  recommendation.  For  the 
purposes  of  the  ensuing  discussion,  references  to  the  DCE  refer 
to  that  part  of  the  IMP  which  interfaces  with  the  host. 
References  to  the  DTE  refer  to  that  part  of  the  host  entity  which 
interfaces  with  the  IMP. 

1  The  Link  Level  DTE/DCE  Interface 
1.1  Scope  and  Field  of  Application  [2.1] 

Although  the  C/30  IMP  supports  both  LAP  and  LAPB  classes  of 
procedures,  DTE  manufacturers  and  implementors  are  strongly  urged 
to  implement  the  LAPB  procedure,  as  this  is  the  only  service 
available  in  all  networks  supporting  the  X.25  Recommendation.  In 
C/30  networks,  use  of  LAPB  provides  for  superior  error  recovery 
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and  link  monitoring  procedures  by  the  DCE. 


1.2  Frame  Structure  [2.2] 

The  address  and  control  fields  consist  of  one  octet  each. 
C/30  IMPS  do  not  support  the  extension  of  either  the  control  or 
the  address  fields.  The  frame  is  required  by  the  implementation 
to  consist  of  an  integral  number  of  octets.  The  C/30  IMP 
maintains  interframe  time  fill  between  frames;  detection  of  idle 
channel  state  by  the  DTE  would  imply  that  the  DCE  is  not 
servicing  the  link. 


1.3  Elements  of  Procedure  [2.31 

1.3.1  Control  Field  Parameters  -  Modulus  [2.3.2.31 

I  frames  are  numbered  sequentially  modulo  8.  Extended 
numbering  (modulo  128)  is  not  supported. 


1.3.2  Rejection  Condition  [2.3.5.61 

After  entering  rejection  condition  by  the  transmission  of  an 
FRMR  or  CMDR  frame,  the  DCE  will  retransmit  the  frame  every  T1 
seconds.  After  N2  retries  without  a  reset  by  the  DTE,  the  DCE 
will  reset  the  link  by  sending  a  SABM  if  it  is  operating 
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according  to  LAPB  procedures.  After  N2  tries  without  a  link 
reset  by  the  DTE,  the  DCE  operating  according  to  LAP  procedures 
will  send  a  DM  response  and  enter  the  disconnected  phase. 

1.4  Procedures  to  Set  the  Mode  Variable  B  [2.4.1] 

The  C/30  'maintains  the  internal  node  variable  B,  as  it 
implements  both  LAP  and  LAPB  classes  of  procedures. 

When  in  the  disconnected  phase  and  in  automatic  transmit 
mode,  the  link  level  software  will,  after  timer  T1  expires, 
transmit  a  DM  frame  to  the  DTE  to  solicit  a  mode-setting  command 
and  restart  timer  TT.  If  the  DTE  transmits  a  SABM  frame,  the  DCE 
will  proceed  according  to  LAPB  procedures.  If  the  DTE  transmits 
a  SARM  frame,  the  DCE  will  proceed  according  to  LAP  procedures. 


1.5  Procedure  for  the  Use  of  the  POLL/FINAL  Bit  [2.4.3] 

The  POLL/FXNAL  bit  is  used  by  the  DCE  in  (Conjunction  with 
the  timer  recovery  condition. 

The  DCE  starts  timer  T1  whenever  it  schedules  for 
transmission  a  frame  which  requires  a  response  from  the  DTE.  and 
it  is  not  already  running.  When  timer  T1  runs  out  before  the 
needed  response  is  received  from  the  DTE.  the  DCE  (re)enters  the 
timer  recovery  condition  and  transmits  an  appropriate  command 
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with  the  POLL  bit  set  to  1.  The  timer  recovery  condition  is 
cleared  when  the  DCE  receives  from  the  DTE  a  valid  unnumbered  or 
supervisory  response  with  the  FImAL  bit  set  to  1 . 

The  DCE  also  uses  the  T1  timer  in  connection  with  automatic 
transmit  mode  in  the  disconnected  phase.  In  this  mode  it  will 
keep  the  T1  timer  running  and  transmit  a  DM  response  to  request  a 
mode-setting  command  from  the  DTE  each  time  it  expires. 

When  the  link  is  in  the  information  transfer  phase,  the  DCE 
operating  according  to  LAPS  {Trocedures  will  ensure  in  the  absence 
of  I  frames  that  the  DTE  link  level  procedures  are  operable  by 
periodic  transmission  of  an  S  frame  with  the  POLL  bit  set  to 
solicit  a  response  from  the  DTE  with  the  FINAL  bit  set.  Failure 
of  the  DTE  to  respond  to  this  command  will  initiate  timer 
recovery  procedures  by  the  DCE.  The  DTE  need  make  no  special 
allowance  for  this  procedure,  since  its  procedures  in  responding 
to  the  S  frame  command  are  simply  those  it  must  employ  according 
to  Recommendation  X.25. 


1.6  Procedures  for  Link  Set-up  and  Disconnection  (LAP)  [2.4.4] 
1.6.1  Link  Set-up  [2. 4. 4.1] 

If  the  DCE  attempting  to  set-up  or  reset  the  link  transmits 
a  SARM  command  N2  times,  its  recovery  action  is  to  attempt  to 
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disconnect  the  link. 


1.6.2  Link  Disconnection  [2.4.4.33 

If  the  DCE  transmits  a  DISC  command  N2  times,  its  recovery 
action  is  to  send  a  DM  response  and  enter  the  disconnected  phase. 


1.7  Procedures  for  Link  Setup  and  Disconnection  (LAPB)  [2.4,53 

1.7.1  Link  Set-up  [2.4.5.13 

If  the  DCE  attempting  to  set-up  or  reset  the  link  transmits 
a  SABM  command  N2  times,  its  recovery  action  is  to  attempt  to 
disconnect  the  link. 

1.7.2  Link  Disconnection  [2.4.5.33 

If  the  DCE  transmits  a  DISC  command  N2  times,  its  recovery 
action  is  to  send  a  DM  response  and  enter  the  disconnected  phase. 


1.7.3  Disconnected  Phase  [2.^.5. 43 

The  C/30  will  not  initiate  link  set-up  while  in  the 
disconnected  phase.  However,  if  it  is  in  automatic  transmit 
mode,  it  will  indicate  a  request  for  a  link  set-up  command  by 
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transmitting  a  DM  response  every  T1  seconds. 


The  C/30  in  disconnected  phase  will  react  only  to  the  frames 
listed  below: 

0  SABM  will  initiate  a  link  set-up,  and  selects  LAPB 

procedures. 

0  SARM  will  initiate  a  link  set-up,  and  selects  LAP 

procedures. 

0  FRMR  received  when  the  B  variable  is  1  (i.e.,  the  last  link 
set-up  was  by  a  SABM  command)  will  be  answered  with  a  DM. 

0  CMDR  received  when  the  B  variable  is  0  will  cause  the  DCE  to 
Initiate  a  link  disconnection  by  sending  a  DISC  command. 

0  DISC  received  when  the  B  variable  is  1  will  be  answered  with 
a  DM  response. 

0  DISC  received  when  the  B  variable  is  0  will  be  answered  with 
a  UA  response. 

0  DM  will  cause  the  DCE  to  initiate  a  link  set-up  by  sending  a 
SABM  if  the  B  variable  is  1 ,  or  a  SARM  if  the  B  variable  is 

0. 

0  Any  other  command  received  with  the  poll  bit  set  will  be 
answered  with  a  DM  response  with  the  final  bit  set. 


All  other  frames  will  be  ignored. 


1.8  Receiving  an  I  Frame  [2. 4. 6. 2] 

DCE  behavior  in  regard  to  acknowledgment  of  I  frames  can  be 
summarized  as  follows: 


When  an  I  frame  is  correctly  received  from  the  DTE.  the  DCE 
starts  a  timer  associated  with  parameter  T2,  if  it  is  not 
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already  running. 

If  K2  I  frames  have  been  received  and  not  acknowledged,  or 
If  no  I  or  S  frames  are  available  for  transmission  before 
the  timer  expires,  the  DCE  will  transmit  an  S  frame  response 
to  carry  the  value  of  VCR). 

The  DCE  will  stop  the  timer  whenever  It  sends  out  a  frame 
containing  an  NCR)  Cl.e.,  an  S  or  I  frame). 


DCE  busy  condition  may  cause  the  I  field  of  Incoming  I 
frames  to  be  Ignored;  please  refer  to  the  following  section  for 
details.  I  frames  containing  zero  length  Information  fields  are 
Indicated  to  the  packet  level  In  the  received  frame.  The  DCE 
Ignores  frames  containing  a  non-integral  number  of  octets. 


1.9  DCE  Busy  Condition  [2.4. 6. 7] 

The  DCE  has  two  levels  of  the  busy  condition.  In  the  first 
level,  called  slow  mode,  any  received  I  frames  are  accepted  by 
transmission  of  an  RNR  response.  In  the  second  level,  called 
stop  mode,  the  DCE  will  discard  any  I  frames  it  receives  from  the 
DTE  until  the  DCE  leaves  the  busy  condition,  and  will  continue  to 
reply  with  RNR  responses.  The  decisions  to  enter  and  leave  the 
two  modes  of  DCE  busy  condition  are  ccntrolled  by  three 
parameters  which  describe  the  length  of  the  queue  of  packets  to 
level  3  in  the  DCE.  Values  for  these  parameters  are  given  In 
Section  J-1 ,15  below. 
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To  clear  the  busy  condition,  the  DCE  will  send  a  REJ  or  RR 
supervisory  frame,  depending  upon  whether  or  not  it  knowingly 
discarded  any  I  frames. 


1.10  Waiting  Acknowledgment  [2.4.6.81 

When  the  T1  timer  runs  out  before  a  transmitted  I  frame  is 
acknowledged  by  the  DTE,  the  DCE  will  restart  timer  T1 ,  and  do 
one  of  the  following:  if  the  DCE  is  operating  according  to  the 
LAPB  procedures,  the  DCE  will  transmit  an  appropriate  supervisory 
command  (RR  or  RNR)  with  the  POLL  bit  set  to  1 ;  if  the  DCE  is 

operating  according  to  the  LAP  procedures,  it  will  set  its  send 

state  variable  to  the  last  NCR)  received  from  the  DTE,  and 

retransmit  the  corresponding  I  frame  with  the  POLL  bit  set  to  1. 

Upon  N2  retransmissions  of  the  S  or  I  frame  command  without 
an  appropriate  response,  the  DCE  will  reset  the  link  by 

transmission  of  a  SABK  (in  LAFB  procedures)  or  SARH  (LAP) 
command. 

1.11  Procedures  for  Resetting  (Applicable  to  LAP)  [2.4.71 

After  transmission  of  a  SARH  command  N2  times,  the  C/30  DCE 
will  attempt  to  disconnect  the  link. 
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The  DCE  does  start  the  T1  timer  whenever  it  sends  a  CMDR 
response,  and  will  retransmit  the  CHDR  response  each  time  it 
expires.  After  N2  retransmissions  of  the  CMDR  response,  the  DCE 
will  send  a  DM  response  and  enter  disconnected  phase. 


1.12  Rejection  Conditions  (Applicable  to  LAP)  [2.4,8] 

The  DCE  will  initiate  a  resetting  procedure  upon  reception 
of  any  spurious  response  frame  or  any  response  frame  with  a 
spurious  final  bit.  Upon  receipt  of  a  CMDR  frame,  the  DCE  will 
reset  the  link  with  a  SARM  command. 


1.13  Procedures  for  Resetting  (Applicable  to  LAPB)  [2.4.9] 

The  DCE  does  start  the  T1  timer  whenever  it  sends  a  FRMR 
response  9  and  will  retransmit  the  FRMR  response  each  time  it 
expires c  After  N?  retrensmisslons  of  the  FRMR  response,  it  will 
attempt  to  reset  the  link  using  a  SABM  command. 
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1.14  Rejection  Conditions  (Applicable  to  LAPB)  [2.4.10] 

1.14.1  Receiving  DM  or  FRMR  in  Information  Transfer  Phase 
[2.4.10.2] 

If  the  DCE  receives  a  DM  response  during  the  information 
transfer  phase,  it  will  transmit  a  DM  and  enter  the  disconnected 
phase.  If  the  DCE  receives  a  FRMR  response  during  the 
information  transfer  phase,  it  will  initiate  a  resetting 
procedure.  If  it  receives  a  spurious  UA  response  during  the 
information  transfer  phase,  the  DCE  will  reset  the  link  by 
sending  a  SABM  command.  Any  unexpected  frame,  or  frame  with  an 
unexpected  final  bit,  will  cause  the  DCE  to  enter  frame  rejection 
condition  and  transmit  a  FRMR  response. 


1.15  Level  2  Implementation-Specific  System  Parameters 

The  DCE  has  three  parameters  associated  with  the  Busy 
Condition.  The  first,  whose  default  value  is  four,  indicates  the 
number  of  I  frames  that  may  be  queued  awaiting  packet  level 
processing  before  the  DCE  enters  the  busy  condition  slow  mode,  in 
which  received  frames  are  acknowledged  with  an  RNR  response. 
When  the  number  of  items  queued  for  Level  3  reaches  the  second 
parameter,  whose  default  value  is  six,  the  DCE  enters  the  busy 
condition  stop  mode,  in  which  received  .1  frames  are  discarded. 
When  the  number  of  items  queued  for  Level  3  while  in  the  busy 
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condition  falls  to  the  third  parameter,  whose  default  value  is 
one,  the  DCE  leaves  the  busy  condition.  The  Administration  may 
configure  each  of  these  parameters  for  each  C/30  DCE  to  any  value 
between  one  and  seven. 

When  receiving  I  frames,  the  DCE  never  allows  more  than  K2 
frames  to  be  received  without  sending  a  frame  that  carries  NCR) 
(that  is,  an  I  or  S  frame).  This  is  an  attempt  to  keep  the  DTE*s 
transmit  window  from  closing.  K2  must  always  be  equal  to  or  less 
than  K,  and  should  be  reduced  for  lines  that  have  long  delay, 
such  as  satellite  lines.  The  Administration  may  configure  K2 
independently  for  each  C/30  DCE  to  any  value  between  one  and 
seven;  the  default  value  is  four. 
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APPENDIX  J.2:  C/30  HDH  Synchronous  Physical 

Level  Specification 

1  Introduction 

This  section  describes  the  functional,  electrical,  and 
mechanical  connection  (the  level  1  connection)  that  is  required 
when  an  HDH  host  is  connected  to  a  BBNCC  C/30  HDH  IMP.  Such 
hosts  reqtilre  a  synchronous  modem  connection  or  the  equivalent, 
which  typically  will  be  supplied  by  the  Administration.  The  host 
will  present  the  DTE  interface  while  the  supplied  modem  equipment 
will  present  the  DCE  interface.  For  the  purposes  of  the  ensuing 
discussion,  references  to  the  DCE  refer  to  that  part  of  the  IMP 
which  interfaces  with  the  host.  References  to  the  DTE  refer  to 
that  part  of  the  host  entity  which  interfaces  with  the  IMP. 

2  Supported  Interfaces 

C/30  HDH  IMPS  presently  support  four  synchronous  level  1 
interfaces  as  shown  below: 

1.  £IA  RS-232.C,  CCITT  V.28  A  V.24,  X.21  bis; 

2.  EIA  RS.449  A  422,  CCITT  V.11,  MIL-ISS-IU 

balanced,  Fed.  Std.  1031/1020; 

3.  EIA  RS-449  A  423.  CCITT  V.10,  MIL-ISS-IU 

unbalanced,  Fed.  Std.  1031/1030;  and 


4.  CCITT  V.35. 
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MIL-188-114  balanced  is  deemed  equivalent  to  RS-449  with 
RS-422,  the  difference  being  that  MIL-188-114  is  more  tolerant  of 
noise  on  signal  common  and  more  tolerant  of  common  mode  noise. 
MIL-188-114  unbalanced  is  deemed  equivalent  to  RS-449  with  RS- 
423.  In  most  cases  where  MIL-188-114  balanced  is  specified, 
mil-188-114  unbalanced  is  also  available,  but  it  is  not 
recommended. 

Table  J.2-1  is  a  dictionary  of  terms  that  relates  the  CCITT 
signal  ID  to  the  EIA  signal  ID  and  to  the  more  common 
abbreviations.  Table  J.2-2  identifies  signals  as  either 
required,  optional,  or  not  used. 

Figure  J.2-1  and  Table  J.2-2  identify  typical  DTE 
connections  to  a  C/30  HDH  DCE.  The  required  host  services  will 
dictate  which  scheme  is  selected  for  a  particular  DTE. 

Table  J.2-3  relates  required  speed  of  service  to  interface 
type.  Tables  J.2-4  through  J.2-6  list  signal  and  pin  names  for 
the  four  supported  physical  interfaces. 

Together,  these  tables  and  figures  serve  as  a  guide  to  level 
1  interface  selection.  From  these,  most  systems  will  be  able  to 
identify  the  most  appropriate  interface.  However.  thi;> 
information  is  not  all-inclusive,  and  other  interface 
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arrangements  may  be  possible.  Various  considerations  may  lead  an 
Administration  to  limit  the  choice  of  physical  interfaces 
available  to  host  DTEs. 

Demarcation  Point 
(mating  connectors) 

DTE  DCE 

I - 1 

I  ! - ]  C - (1)  Modem  RS-232-C,  RS-449,  V.35 

i  I 

I  j - ]  C - (2)  LDM  RS-232-C,  RS-449 

i  HOST  i 

;  I - ]  [ - (3)  Null  Modem  Cable 

!  I 

I  I——]  [——(4)  SME  Cable  plus  clock  source; 

i _ I  RS.232-C,  RS-449 

Figure  J.2-1  Typical  Level  1  Connection  Schemes 
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EIA 

CCITT 

ABBREV 

NAME 

ID 

ID 

NAME 

AA 

101 

FG 

Frame  (Chassis/Protective)  Ground 

AB 

102 

SG 

Signal/Supply  Common 

SC 

102a 

— 

RS-449  DTE  Common 

RC 

102b 

— 

RS-449  DCE  Common 

BA 

103 

TD 

Transmit  Data 

BB 

104 

RD 

Receive  Data 

CA 

105 

RTS 

Request  to  Send 

CB 

106 

CTS 

Clear  to  Send 

CC 

107 

DSR 

Data  Set  Ready 

CD 

108.2 

DTR 

Data  Terminal  Ready 

CF 

109 

DCD 

Data  Carrier  Detect 

CG 

110 

SQ 

Signal  Quality 

CH 

111 

— 

Signal  Rate  Selector  to  DCE 

Cl 

112 

•• 

Signal  Rate  Selector  to  DTE 

DA 

113 

ETC 

External  Transmit  Clock 

DB 

114 

TC 

Transmit  Clock 

DD 

115 

RC 

Receive  Clock 

•• 

116 

•• 

Select  Standby 

117 

•• 

Standby  Indicator 

SBA 

118 

STD 

Secondary  Transmit  Data 

SBB 

119 

SRD 

Secondary  Receive  Data 

SCA 

120 

SRS 

Secondary  Request  to  Send 

SCB 

121 

SCS 

Secondary  Clear  to  Send 

SCF 

122 

SCD 

Secondary  Carrier  Detect 

SCG 

123 

SSQ 

Secondary  Signal  Quality 

— 

124 

Select  Frequency  Group 

CE 

125 

RI 

Ringing  Indicator 

— 

126 

— 

Select  Transmit  Frequency 

•• 

127 

— 

Select  Receive  Frequency 

128 

External  Receive  Clock 

— 

129 

RR 

Request  tc  Receive 

— 

130 

— 

Secondary  Transmit  Tone 

131 

— 

Receive  Character  Timing 

132 

— 

Return  to  Non-Data  Mode 

•• 

133 

RTR 

Ready  to  Receive 

134 

— 

Received  Data  Present 

•• 

136 

— 

New  Signal 

140 

RL 

Remote  Loopback 

141 

LL 

Local  Loopback 

•• 

142 

TM 

Test  Status  Monitor 

•• 

191 

— 

Transmit  Voice  Answer 

— 

192 

— 

Receive  Voice  Answer 

Table  J.2-1  EIA  and  CCITT  Interchange  Circuits 
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Scheme  (From 

Fig.  B-1)  Explanation 

(1)  Modem  Any  of  the  four  supported  physical  interfaces 

providing  service  over  long  haul  leased  voice 
grade  or  group  grade  telephone  facilities. 

(2)  Limited  Distance  Modem 

LDM  generally  available  at  9600  b/s  and  below  in 
an  RS-232-C  version.  Other  types  are  available 
for  all  speeds. 

(3)  Null  Modem  A  Null  Modem  is  a  length  of  cable  with  the  signal 

leads  wired  so  as  to  present  a  DCE  interface.  To 
be  used  in  local  connection  schemes  where  either 
the  host  DTE  or  the  C/30  IMP  has  a  clocking 
source  capability.  All  four  supported  level  1 
interfaces  are  available.  If  host  DTE  clock  and 
C/30  IMP  clock  are  both  available,  DTE  clock  will 
be  preferred. 

(4)  Synchronous  Modem  Eliminator 

SME  is  a  length  of  cable  with  a  hardware  device 
interjected.  The  device  allows  rewiring  of 
signals  so  as  to  present  a  DCE  interface.  The 
device  also  provides  clocking  when  neither  the 
host  DTE  nor  the  C/30  IMP  has  such  capability. 

All  four  supported  level  1  Interfaces  are 
available. 


Table  J.2-2  Typical  Level  1  Connection  Schemes 
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Physical 

Signalling  Rate 

in  Kb/s 

Interface  1 

1.2  to  9.6  14.4,  19.2 

48  and  above 

RS-232-C  (and  equiv.) 

A  A 

- 

RS-449/422  balanced 
(and  equiv.) 

A  A 

A 

RS-449/423  unbalanced 
(and  equiv.) 

A 

• 

CCITT  V.35 

A  s 

•  X 

Legend 

Available 

Not  available 

A 

Table  J-2.3  Interface  Type  by  Service  Speed 
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Signal  Name  Abbrev  Pin  No.  EIA  ID  Signal  Sc 

Frame  Ground  FG  1  AA  DTE/DC 

Transmitted  Data  TD  2  BA  DTE 

Received  Data  RD  3  BB  DCE 

Request  to  Send  RTS  4  CA  DTE 

Clear  to  Send  CTS  5  CB  DCE 

Data  Set  Ready  DSR  6  CC  DCE 

Signal  Ground  DTE 

Ext.  Transmit  Clock  ETC  24  DA  DTE 

Wired  Spare  —  18  —  — - 

Wired  Spare  —  22  —  — - 

Wired  Spare  —  25  —  — — 

Required  pins;  1,  2,  3«  4,  5,  6,  7»  8,  15f  17.  20,  24 
Optional  pins:  9i  10,  18,  22,  25 

Notes* 

1.  The  DTE  will  present  a  CANNON  DB-25P  male  connector 
with  pinouts  as  above  or  equivalent  hardware  with 
identical  pinouts. 

2.  The  DCE  will  present  a  CANNON  DB-25S  female 
connector  or  equivalent. 


Table  J.2-4  RS-232-C  Interface 
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Signal  Name  Abbrev 

Pin  Nos. 

EIA  ID 

Signal  Source 

Send  Data 

SD 

4,22 

BA 

DTE 

Send  Timing 

ST 

5,23 

DB 

DCE 

Receive  Data 

RD 

6,24 

BB 

DCE 

Request  to  Send 

RTS 

7,25 

CA 

DTE 

Receive  Timing 

RT 

8,26 

DD 

DCE 

Clear  to  Send 

CTS 

9,27 

CB 

DCE 

Local  Loopback 

LL 

10 

DTE 

Data  Mode 

DM 

11,29 

CC 

DCE 

Terminal  Ready 

TR 

12,30 

CD 

DTE 

Receiver  Ready 

RR 

13,31 

CF 

DCE 

Remote  Loopback 

RL 

14 

— 

DTE 

Terminal  Timing 

TT 

17,35 

DA 

DTE 

Test  Mode 

TM 

18 

— 

DCE 

Signal  Ground 

SG 

19 

AB 

DTE/DCE 

Receive  Common 

RC 

20 

RC 

DCE 

Send  Common 

SC 

37 

SC 

DTE 

Wired  Spare 

•• 

1 

•• 

••• 

Wired  Spare 

— 

3,21 

Required  pins: 

^,22;  5 

,23;  6,24 

;  7,25;  8,26 

5  9,27; 

11,29; 

12,30;  13 

,31;  17,35; 

19i  20j  37 

Optional  pins: 

10;  14; 

18;  1;  3 

,21 

Notes* 


1.  The  DTE  will  present  a  CANNON  DC-37P  male  connector 
with  pinouts  as  above  or  equivalent  hardware  with 
identical  pinout. 

2.  The  DCE  will  present  a  CANNON  DC-37S  female 
connector  or  equivalent. 


Table  J.2-5  R3-M49  Interface  (and  equivalents) 
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Signal  Name 

Abbrev 

Pin  Nos. 

EIA  ID 

Signal  Source 

Frame  Ground 

FG 

A 

AA 

DTE/DCE 

Signal  Ground 

SG 

B 

AB 

DTE/DCE 

Transmit  Data 

TD 

P/S 

BA 

DTE 

Receive  Data 

RD 

R/T 

BB 

DCE 

Request  to  Send 

RTS 

C 

CA 

DTE 

Clear  to  Send 

CTS 

D 

CB 

DCE 

Data  Set  Ready 

DSR 

E 

CC 

DCE 

Data  Carrier  Detect 

DCD 

F 

CF 

DCE 

Local  Loopback 

LL 

K 

.. 

DTE 

Ext.  Transmit  Clock 

ETC 

U/W 

DA 

DTE 

Transmit  Clock 

TC 

Y/aa 

DB 

DCE 

Receive  Clock 

RC 

V/X 

DD 

DCE 

Required  Pins: 

Optional  Pins: 

Notgg! 

A;  B; 
V/X 

K 

P/S;  R/T;  C; 

D;  E;  F; 

U/W;  Y/aa; 

1.  The  DTE  will  present  a  Winchester  MRA(C)-3MD-JTCH-H8 
male  connector  with  pinout  as  aoove  or  equivalent 
hardware  with  the  identical  pinout. 


2.  The  DCE  will  present  a  mating  female  connector. 


Table  J.2-6  V.35  Interface 


J.2-9 
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Report  No.  1822 


BBN  Conmunlcetions  Corporation 


Appendix  K:  CCITT  Recoamendatlon  X.25  1980 
Link  Access  Procedure  (LAPB) 


i 

»»Ii 
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2  Uak  acctM  pract^wt  ktom  tht  DTE/DCE  Urttffact 
11  Scope  attdfieU  of  appikatioo 

11.!  The  Link  Access  Procedures  (LAP  and  LAPS)  are  described  as  the  Link  Level  Element  and  are  used  for 
data  interchange  between  a  DCE  and  a  DTE  operating  in  user  classes  of  service  S  to  1 1  as  indicated  in 
Recommendation  X.l  (1). 

11.2  The  procedures  use  the  principles  and  terminology  of  the  High  Level  Dau  Link  Control  (HDLQ 
procedures  spedHed  by  the  International  Organiaation  for  Standardiauion  (ISO). 

IIJ  The  traiuraission  facility  is  duplex. 

11.4  DCE  compatibility  of  operation  with  the  ISO  balanced  dau  of  procedure  (Clau  BA,  options  18)  is 
achieved  using  the  provisions  found  under  the  hcadinp  annotated  u  “app'I^le  to  LAPB”  in  this  Recommends' 
tion. 

DTE  manufacturers  and  impiementon  must  be  aware  that  the  procedure  hereunder  described  as  LAPS  will 
be  the  only  one  available  in  all  networks. 

Likewise,  a  DTE  may  continue  to  use  the  provisions  found  under  the  headings  annotated  as  “applicable  to 
LAP”  in  this  Recommendation  (in  those  network*  supporting  such  a  procedure),  but  for  new  DTE  implemenu- 
tions.  LAPB  should  be  preferred. 

Note  •  Other  possible  applications  for  fhrtb«  study  are,  for  example: 

-  two>way  alternate,  asynchronous  responu  mode: 

-  two>way  simultaneous,  normal  response  mode: 

-  two>way  alternate,  normal  responu  mode. 


12  home  stmeture 

111  All  transmissions  are  in  frames  conforming  to  one  of  the  formats  of  Table  Iy'X.25.  The  Rag  preceding  the 
address  Reid  is  dcRncd  as  the  opening  Rag. 


112  flog  segoeoce 

All  frames  shall  start  and  end  with  the  Rag  sequence  consisting  of  one  0  followed  by  six  condguous  Is  and 
one  (X  A  single  Rag  may  be  used  as  both  the  dosing  Rag  for  one  frame  and  the  opening  Rag  for  the  next  frame. 

12J  Addnu/Md 

The  addrms  Rdd  shall  consist  of  one  octet.  Tne  coding  of  the  address  Reid  is  deschbsd  in  |  I.A2  below. 
Faukle  VHU  -  Rec.  )L2S 
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TABLE  I/X2S 

1234S47I 

12343471  12343471 

14  to  1 

12343471 

Flat 

Addrca 

Comroi 

PCS 

Flat 

F 

A 

C 

PCS 

F 

01  1  1  1  1  1  0 

l-btu 

14^ 

0  1  1  1  1  1  1  0 

PCS  Ptit  Cfeaddag  Siq— iw 


12343471 

12343471 

1  234347  1 

14  to  1 

12343471 

flit 

Mf&nm 

Comroi 

laforaaisaa 

PCS 

Flat 

F 

A 

C 

1 

PCS 

F 

01 1  1  1  1  1  0 

Ms 

Khiu 

14-Mu 

0  1  1  1  1  1  1  0 

PCS  Frasa  OMckiat 


12.4  Control  fitU 

The  oontrol  field  shill  eoiuist  of  one  octet  The  content  of  this  field  is  described  in  1 132  bdow. 

Nott  -  The  use  of  the  extended  oontrol  field  is  a  subject  for  further  study. 

22J  Imformmnom  fkU 

The  infomution  field  of  a  frame  is  unrestrioad  with  respect  to  code  or  grouping  of  bits  except  for  the 
packet  formats  spcafied  in  f  6  below. 

See  H  13.4.10  and  14.1  IJ  bdow  with  regard  to  the  maximum  information  field  length. 

116  Trwpmrtnqt 

The  DTE  or  DCE,  when  transmitting,  shall  examine  the  frame  contem  between  the  two  flag  sequences 
induding  the  address,  oontrol.  information  and  FCS  sequences  and  shall  insert  a  0  bit  aAer  ail  sequences  of 
3  oondguotts  1  biu  (induding  the  last  3  bits  of  the  FCS)  to  ensure  ihs:  s  flag  sequence  is  not  simulated.  The  DTE 
or  DCE,  when  raoemng.  shall  examine  the  fiamc  content  and  shall  discard  any  0  bit  which  directly  follows 
3  contiguous  I  bits. 

117  fneme  cKrddmf  (FCS) 

The  FCS  shall  be  a  I6>bit  sequence.  It  shall  be  the  ones  complement  of  the  sum  (modulo  2)  of: 

1)  The  remainder  of  s*  (s’*  I)  divided  (modulo  2)  by  the  generator 

polynomial  x**  4-  x'*  >  x*  4-  I.  where  k  is  the  number  of  btu  in  the  frame  existing  b^wten.  but  not 
induding.  the  final  bit  of  the  opening  flag  and  the  first  bit  of  the  FCS.  cxduding  biu  msened  for 
traesparency.  and 

2)  the  remainder  aAer  iButtiplication  by  x^*  and  then  division  (nodulo  2)  by  the  gcncra^’vir  pclynominal 

x^*  4-  4-  X*  4-  1.  of  the  content  of  the  frame,  existing  birwetn  but  not  induding.  the  final  bit  of 

the  opening  flag  and  the  first  bit  of  the  FCS.  cxduding  biu  msened  for  transparency. 

Faackte  VI112  -  ten.  X2S 
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As  a  typical  implctnenyition,  at  th«  transmitter,  the  initial  remainder  of  the  division  is  preset  to  all  Is  and 
is  then  modined  by  division  by  the  generator  polynominal  (as  decribed  above)  on  t^  address,  control  and 
information  fieids:  the  Is  complement  of  the  resulting  remainder  is  transmitted  as  the  I64)it  FCS  sequence. 

At  the  receiver,  the  initial  remainder  is  preset  to  all  Is.  and  the  serial  incoming  protected  bits  and  the  FCS. 
when  divided  by  the  generator  polynominal.  will  result  in  a  remaindtf  of  OOOIllOtOOOOlIll  (x**  through  r, 
respectively)  in  the  absence  of  transmission  errors. 

?  ?  i  Order  of  bit  rransmuxioM 

Addresses,  commands,  responses  and  sequence  numbers  shall  be  transmitted  with  the  low  order  bit  flrit 
(for  example,  the  nm  bit  of  the  sequence  number  that  b  transmitted  shall  have  the  weight  2f). 

The  order  of  transmitting  bits  within  the  informatioe!  field  is  not  spedfied  under  }  2.  The  FCS  shall  be 
transmitted  to  the  line  commencing  with  the  coeffident  of  the  highest  term. 

fiote  -  The  low  order  bit  is  defined  *s  bit  t.  m  depicted  in  Tables  t/X.25  to  VX.2S. 


119  iM^eiid  fiamet 

A  frame  «ol  properiy  boundeo  by  two  Hags,  or  having  fewer  than  32  bits  between  flags,  is  an  invalid 

frame. 

2J.tO  Frame  ohomoe 

Aborting  a  frame  is  performed  by  transmitting  at  least  seven  contiguous  Is  (with  no  inserted  Os), 
lil  I  Imterframe  time  fitt 

Intcrframe  time  fill  is  accompitshed  by  transmitting  contiguous  flags  between  frames. 


1112  Uak  dbeumei  states 
mil  Actire  duumei  state 

A  channel  is  in  an  active  condition  when  the  DTE  or  DCE  is  actively  transmitting  a  frame,  an  abortion 
sequence  or  interframe  time  fUL 


1112.1  Idle  chmtmei  state 

A  channel  b  defined  to  be  in  an  idle  condhton  when  a  oonoguoua  Is  state  b  detected  that  pcrsuis  for  at 
Icaai  IS  bit  times. 

Note  I  -  The  aoion  to  be  taken  upon  deeecoon  of  the  idle  cheneel  stale  b  a  subjea  for  further  study. 
Note  2  -  A  link  channd  as  defined  here  b  the  means  of  transmission  for  one  direcrion. 

13  Elements  of  peaeedure 

U.l  The  demenu  of  prooedufu  are  defined  in  terms  of  sctioiu  that  occur  on  receipt  of  commands  at  a  DTE  or 
DCE. 

The  elemena  of  procedure  specified  below  oontaia  a  seketioo  of  commands  and  responses  relevant  to  the 
link  and  tyscca  configuration  dmenbed  in  |  11  above. 

A  procedure  b  derived  from  them  dements  of  procedure  and  b  described  in  |  14  below.  Together  ff  ^ 
rud  2J  form  the  general  requirements  for  the  proper  management  of  the  aooesa  link. 

_ rmetek  Vim  ~  tee.  X-25 _ _ 12 /S  3 
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13  J  Control  field  formou  mmd  swe  rviabtea 

13^1  Control  field  /ormmti 

Tbc  ooatrol  fidd  ooautM  a  oommand  or  a  rcapoaae,  and  lequanoa  nunbcn  where  applicable. 

Three  types  of  control  Held  fonnau  (see  Table  1/X35)  are  osed  to  perfona  numbered  information  transfer 
(I  frames),  numbered  supervisory  functions  (S  fraams)  and  unoumberud  contre!  fusedoss  (U  frasss). 

TAKLE2>X3S 


233.1. 1  Ittfoemotion  trmmfer  foemat  -  / 

Tbc  I  format  is  need  to  perform  an  infonaatioo  tranafer.  Tbc  runebons  of  N(S).  N(R)  and  F/F  are 
independent;  Lc..  each  I  fram  baa  aa  N(S).  an  N(R)  which  may  or  may  not  acfcaowiodfc  addiuonal  1  frames 
rcoeivod  by  the  DTI  or  DCfc.  and  a  F/F  bit 


2J3.!3  Sm^erneory Jdemoi  •  S 

The  S  format  is  uaad  to  perform  link  supmiaory  control  fuacbons  such  as  acknewlud|f  1  framm,  m^ucss 
retraasmuaion  of  I  framoa,  and  to  ruquem  a  aemporary  ■mpenaion  of  trananuasion  of  )  fraaMa. 
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2JJ.4  Fnmt  fOriabta  se^utiKt  mtmbtn 


Smd  state  saMk  VfS) 

Th«  i«od  salt  varitWt  draoCM  Um  ttqMnca  number  of  tht  ntit  in-requenos  I  fremt  to  bn  tn<..'"mia3d. 
The  semi  ifiie  mriible  an  tUa  oa  the  vtiae  0  throuih  modulus  minus  1.  Tlie  vtiue  of  the  send  ustt  vinsWe  is 
incFcmenied  by  I  with  each  sucoasive  I  frame  transmission,  but  u  the  DCE  cannot  jacaed  N(R)  of 
received  i  or  3  rrwwe  by  mot*  th^yi  ihi  »sas;TT?*!Tyt  number  of  sasssandini  I  frama  (kV.  Tlie  value  of  k  is  defined 
in  1 1411.4  below. 


2J  J.42  Send  lefMwe  mtmber  N(S) 

Only  I  faama  contain  N(S),  the  send  sequenos  number  of  transmicicd  framea.  Prior  a  transraissioo  of  an 
in-scquenca  I  fiam  u  the  value  of  N<S)  is  at  equal  a  the  value  of  the  and  state  variable 


2J.144  /Ucetve  state  foriakk  VfR) 

The  laceive  state  variable  denota  the  sequence  nsmba  of  the  neat  in-sequence  I  frame  a  be  received.  The 
recaive  sum  variable  can  take  on  the  vaha  0  through  modula  minus  1.  The  value  of  the  receive  «aa  variable  is 
inoemenad  by  one  with  the  rucsipi  of  an  error  free,  in-aquence  I  frame  whoa  send  aquence  number  N(S) 
equals  thr  receive  state  variable. 


2J.14.4  JUcmve  jegueea  number  MfR) 

All  I  fraeae  and  S  f^ama  oontaia  N(R),  tie  expected  sequence  number  of  the  next  received  I  frame.  Prior 
to  traasmissiott  of  a  frame  of  the  above  types,  the  viNa  of  N(R)  is  m  -qual  a  the  current  value  of  the  receive 
state  variable.  N<R)  indkaim  that  the  OTR  or  OCE  uansmitting  the  N(R)  hae  received  conectly  aU  I  fraam 
numbered  up  a  and  induding  N<R)  - 1. 


2.)  J  AMcram  of  the  foO/fiaal  Mr 

The  PoU/Fiaal  (P/F)  bit  servm  a  fbnehon  in  both  command  frunm  and  repona  framm.  !n  command 
framm  the  P/P  bit  ia  refened  a  m  the  P  bk.  In  leapona  framm  k  ia  referred  a  m  tht  F  bit. 

The  urn  of  the  P/F  bk  it  dmoibed  ia  I I4J  bdow. 


13.4  Commamsb  and  lesyonrer 

The  fe!)owiag  commanda  and  respensm  will  be  used  by  cither  the  DTR  or  DCE  and  are  repreanted  in 
Table  i/XSJ. 

The  oomesaads  and  responsm  are  m  followr: 

23.4.1  lafanmanem  (1)  commend 

The  fbaction  of  the  tafcnuacan  (I)  command  a  a  trsnsfer  /fom  a  dad  link  sequentially  aumbcfed 
framm  ooautniag  an  infonnaiioa  ftdd. 

13.4.3  ileccm  ready  (MMJ  command  and  mfmmtt 

The  receive  ready  (RR)  superriaocy  fhunc  ia  used  by  the  DTE  cr  DCE  a: 

1)  indkaie  a  is  ready  a  reenvt  aa  1  fraaa: 

2)  ackaovtadge  prcvieus^y  reoaivad  1  framm  caunbemd  ep  a  and  mdudiag  N<R)  >  ^ 

RR  may  be  ttsad  a  dem  a  bam  neadmiaa  ihm  wae  miismad  by  the  transmtsaioa  of  RNR.  The 
RR  command  wkh  the  P  bk  sal  a  t  euy  be  aead  by  the  DTE  or  DCE  a  ask  far  tim  sttam  of  the  OCE  or  DTE, 
rmpecsivcty. 


13.0  Mejec(M£J)cmm0mamd  mdfmpame 

The  rejaa  (REJ)  wpervkocy  frima  is  uaae  by  the  OTH  or  DCE  a  requaei  repaatmimioa  of  I  fkaaam 
startsf  entb  the  frame  eumbered  N<R).  I  framm  eembered  .N(R)  -  I  sad  belcw  ire  sckaowlcdfed.  AddttaaaJ 
t  pcadiag  iatCMl  transttssioa  auy  be  tramawead  foilewutg  the  rmranssucad  !  fnaMts). 
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1  2  3  4  5  6  7  1 


Esicndliit 

H 

N<S) 

B 

N(R> 

M  (mi«e 

ready) 

RNR  (mf«e 
•et  ready) 

RBJ  (reimi) 

RR  (fecdsi 

ready) 

RNR  (renNe 

BOtriidy) 

REJ  (rejaa) 

n 

P/F 

P/F 

P/F 

N(R) 

N(R) 

N(R) 

1 

SARM  im 

MjmehroaOTs 

rmp—smede) 

DM  (ilintiannii 

■cdt) 

1111 

P/F 

0  0  0 

SAIM  (aai 

asyochrowoos 

balaaoMaude) 

1111 

F 

1  0  0 

DISC  (dltmiwT) 

110  0 

F 

C  1  0 

UA  (aanaiiibwwl 

atkaamiaS^ 

BBI 

1 

■ 

CMDR  (eonmtf 
teieci) 

FRMR  (fraaw 

rma) 

1110 

L_  ^ 

F 

0  0  I 

Nof»  1  -  ‘n:^  Mel  for.  lad  uit  of,  addltioaal  commaadi  and  mfomm  tut  for  imbn  ndy. 

Norn 2  •  DTEt  do  aoi  tMv«  to  teotanoii  bodi  SARM  aod  SAIM;  ftinbwnwn  DM  nad  SAIM  i»Hd  ooe  be  mod  if  SAJtM  only 
ii  and. 

Mon  J  -  Ul.  RNR  ad  UEJ  npnvitary  eoraad  ftvMi  an  aoi  and  by  ite  DC£  Mm  SAJtM  h  uaM  (LAf). 


Only  one  R£J  exception  condition  for  a  given  direction  of  inforrsation  transfer  may  be  esubltshed  at  any 
time  The  REJ  exception  condition  t3  cleared  (reset)  upon  the  receipt  of  an  I  frame  with  an  N(S)  equal  to  the 
N(R)  of  the  REJ. 

The  REJ  command  with  the  P  bit  set  to  1  may  be  used  by  the  DTE  or  DCE  to  ask  for  the  surus  of  the 
DCE  or  DTE,  respectively. 

2J.4.4  .teernw  eor  (RI^R)  eomm^d  a$td  rtspom* 

The  receive  not  ready  (RNR)  supervisory  frame  is  used  by  the  DTE  or  DCE  to  indicate  a  busy  condition. 
Le.,  temporary  inability  to  accept  additional  incoming  I  frames.  I  frames  numbered  up  to  and  including  N(R)  -  1 
are  acknowledged.  I  frame  N(R)  and  subsequent  I  frames  received,  if  any,  are  not  acknowledged:  the  acceptance 
status  of  these  1  frames  will  be  indicated  in  subsequent  exchanges. 

An  indication  that  the  busv  condition  has  cleared  is  communicated  by  the  transmiv^on  of  a  UA,  RR,  REJ 
or  SABM. 

The  RNK  i'aaaaod  with  the  P  bat  set  to  1  may  be  used  by  the  DTE  or  DCE  to  ask  for  the  status  of  the 
DCE  Of  DTE,  respectively. 

2J.4J  5«r  asy^.skrxmem  rtsporut  modt  (SARkt)  eommmnd 

The  SARM  unnumbered  command  is  used  to  place  the  addressed  DTE  or  DCE  in  the  asynchronxous 
raspotts*  mode  (ARM)  infonnadon  transfer  pshaa^ 
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No  information  field  is  permitted  with  the  SARM  command.  A  DTE  or  DCE  confirms  acap^<»^ 
SARM  by  the  transmission  at  the  first  opportunity  of  UA  response.  Upon  acceptance  of  this  command,  the  DTE 
or  DCE  receive  lUte  variable  V(R)  is  set  to  0. 

Previously  transmitted  I  frames  that  are  unacknowledged  when  thU  command  is  acsdoned  remain 
unacknowledged. 


2J.4.6  5er  asynchronam  baianeed  mod*  (SaBM)  command 

The  SABM  unnumbered  command  is  used  to  place  the  addressed  DTE  or  DCE  in  the  asynchronous 
balanced  mode  (ABM)  information  transfer  phaiA 

No  information  field  ;s  permitted  with  the  SABM  command.  A  DTE  or  DCE  confirms  accepttnw^ 
SABM  by  the  transmission  at  the  first  oppoitusity  of  a  UA  response.  Upon  acceptance  of  this  command  the  DTE 
or  DCE  send  variable  V(S)  and  receive  state  variable  V(R)  are  set  to  0. 

Previously  transmitted  I  frames  that  are  unacknowledged  whrs  this  command  is  actioned  remain  unack* 
nowledged. 


2J.4.7  Disconnec:  (DISC)  command 

The  DISC  unnumbered  com.mand  is  used  to  terminate  the  mode  previously  set  It  is  used  to  inform  the 
DTE  or  DCE  receiving  the  DISC  that  the  DCE  or  DTE  sending  the  DISC  U  suspending  operation. 

No  information  field  U  permitted  with  the  DISC  coi!*mand.  Prior  to  actioning  the  comsaad,  the  DTE 
or  DCE  receiving  the  DISC  confirms  the  acceptance  of  DISC  by  the  transmission  of  a  UA  response.  The  DCE  or 
DTE  sending  the  DISC  enters  the  disconnected  phase  when  it  receives  the  acknowledging  UA  response. 

Previously  transmittw!!  I  frames  that  are  unacknowledged  when  this  command  is  scooned  remain 
unacknowledged. 


2J,4,5  Ijnmummrwd  acknowlidgemgni  (UA)  rtspons* 

The  UA  unnumbered  response  is  used  by  the  DTE  or  DCE  to  acknowWge  the  receipt  and  scceptance  of 
the  U  format  commands.  Received  U  format  commands  are  not  aaioned  until  the  UA  response  is  transmitted 
The  UA  response  is  transmitted  as  directed  by  the  received  U  format  command  No  information  field  is  permitted 
with  the  UA  response. 


2J.4.9  Diseonneatd  mod*  (DM)  rtioons* 

The  DM  unnumbersd  response  is  used  to  report  s  status  wbert  the  DTE  or  DCE  is  logically  disconnect^ 
from  the  link,  and  is  in  the  disconnected  phase.  TTie  DM  response  b  sent  in  phase  to  rsqueit  a  set  mod* 
coeimand  or,  if  sent  in  responje  to  the  reception  of  a  sec  mo^  command  to  inform  the  DTE  or  DCE  that  the 
DCE  or  DTE.  respectively,  b  still  in  the  dbconnected  phase  and  cannot  action  the  sec  mode  command  No 
information  field  is  permitted  with  the  DM  response. 

A  DTE  or  DCE  in  a  disoonnected  phase  will  monitor  received  commands,  and  will  to  SABM  s^ 
outlined  in  |  I4J  bdow  and  will  respond  DM  with  the  F  bit  set  to  I  to  any  oUier  ecsunaad  mceived  with  the 
P  bit  sec  to  1. 


2J.4.10  Commend  rtj*a  (CMDR)  rtspons*;  From*  r*y*a  (FKMR)  rtsfotu* 

The  CMDR  (FRMR)  response  b  used  by  the  DTE  or  DCE  to  report  an  error  condition  not  recoverable  by 
titransmiwon  of  the  identical  fraffle;  Le..  one  of  the  following  oonditiona.  which  results  from  the  reoeipc  of  a 
frame  without  FCS  error 

1}  the  receipt  of  a  command  or  response  that  b  iavaUd  or  not  implemented; 

2)  the  receipt  of  an  1  frame  with  an  information  field  which  exceeds  the  maximum  established  length; 

3)  the  receipt  of  an  invalid  N(R)  (in  the  case  of  LAP.  see  f  14.8.1); 
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4)  the  recap!  of  a  frame  with  an  information  Acid  which  is  not  permitted  or  the  receipt  of  an  S  or 
U  frame  with  incorrect  length. 

>Vn  invalid  N(R)  U  defined  as  one  which  points  to  an  1  frame  which  has  previously  been  transmitted  and 
acknowledged  or  to  an  I  frame  which  has  not  transmitted  and  is  not  the  next  sequential  I  frame  pending 
transmission. 

>Vn  information  field  which  immediately  follows  the  control  field,  and  consists  of  3  ooets,  is  returned  with 
this  response  and  provides  the  reason  for  the  CMDR  (FRMR)  response.  This  format  is  given  in  Table  4/X.25. 


TABLE  4/X.2S 

CMOR  (FItMR)  iafemaOM  AsM  fencM 
laforauttiOB  (kid  bin 


I  2  3  <  5  «  7  I  *  10  It  12  13  14  IS  14  17  II  •»  20  21  22  23  24 


-  Rtkeud  frtae  eoatroi  fWd  H  dK  coacroi  field  of  the  rweived  (mine  which  eeuMd  the  CMHUBd  (franc)  rcka. 

-  V(S)  is  the  eitnee*  lead  umt  vnriabk  vah»c  ci  the  DTE  or  DC£  report!^  the  tV)ccuoQ  coediiion  (bii  10  ■  low  order  bit). 

-  V(R)  is  the  otmai  receive  jute  vuicble  vihte  st  the  DTI  or  DCE  rtporbat  the  rejKtioo  cooditioo  (bh  14  ■  low  order  bn). 

-  SCI  u>  I  iadieitei  ths(  the  oxurol  fkid  receivtd  ttad  rammed  in  biu  i  threuah  I  wu  invalid  or  not  iapkoMiited. 

-  X  set  to  I  indicates  that  the  control  (Wd  racrived  esd  rentreed  to  bits  I  throtifh  I  was  coosidend  invalid  bwausc  the  fratne 

eontatoed  an  toforautioa  Aeid  which  is  not  pesnitted  or  U  an  S  or  U  frame  with  tocorract  lenith.  Bit  W  must  bir  m  ic  I  m 
oonjunaion  with  this  bit.  _ 

>  Y  set  to  1  that  the  toformatioo  fMd  received  esenwied  the  suxtomta  twabiiibed  capacity  of  the  DTE  or  DCE  raportiag 

the  rajeciicts  eoodttion. 

>  Z  set  to  I  that  the  cantrtJ  fWd  raetoved  and  rammed  to  hits  I  throuih  I  comatoed  la  invalid  N(R). 

/Vow  >  Bits  f.  13  tad  21  to  24  shall  be  set  to  0  for  ^DR.  For  FRMR,  hiu  f  ed  21  to  24  mail  be  Mt  to  0-  Bit  13  shall  be  set  to  I 

if  the  fraoie  reiected  was  a  neponsc,  tad  set  to  0  if  the  frame  rejected  was  a  cwaiaeftd. 


2.'JJ  Excfprion  conJfboa  rtporting  amd  rteovery 

The  error  recovery  procedures  which  are  tvailable  to  oTca  recovery  following  the  detection /occurrence  of 
an  exenpuon  condition  at  the  link  level  arc  described  below.  Exception  conditions  described  are  those  situations 
which  m»y  o/xur  as  the  result  of  transmiuion  errors,  DTE  or  DCE  or  operational  situations. 


ZJJ.l  Mujyeomdinon 

The  busy  condition  resulu  when  a  DTE  or  DCE  is  temporarily  unable  to  continue  to  receive  I  frame  due 
to  internal  constraints,  cr.,  receive  buffering  limiutions.  In  this  sue  an  RNR  frame  is  trantmined  from  the 
busy  DTE  or  DCE.  I  frame  pending  transmission  may  be  trasumined  from  the  busy  DTE  or  DCE  prior  to  or 
following  the  RNR,  Clearing  of  the  busy  oondidon  is  indicated  u  described  in  |  2J.4.4  above. 

13S2  N(S)  srfwencr  error 

The  information  field  of  all  I  frame  whose  N(S)  doe  not  equal  the  receive  suu  variable  V(R)  will  be 
discarded. 

An  N(S)  sequence  exception  cendiooR  occurs  in  tbe  receive  when  an  I  frame  received  error-fme  (no  FCS 
error)  ooateint  an  N(S)  which  is  not  equal  to  the  receive  statt  variable  at  the  receiver.  The  reectve  does  not 
acknowledge  (incxemem  its  receive  mate  variable)  the  I  frame  cauiiog  the  tequenoe  error,  or  any  I  frame  which 
may  follow,  u.itil  an  I  frame  with  the  correct  N(S)  is  received. 
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A  DTE  or  DCE  which  receives  one  or  more  I  frames  having  sequence  errors  but  otherwise  e^o'-fre*  shall 
accept  the  cmftrol  information  contained  in  the  N(R)  field  and  the  P  bit  to  ^o™  Unk  ^nt^l 
receive  acknowledgement  of  previously  transmitted  I  fram«  and  to  cause  the  DTE  or  DCE  to  ^ 

ITTriiet^rre %  retransmitted  I  frame  may  conuin  an  N(R)  field  and  P  bit  that  are  updated  front  and 
therefore  different  from,  the  ones  contained  in  the  originally  transmitted  I  frame. 


2J.5J  REJ  rgco¥try 

TTie  REJ  is  used  to  initiate  an  exception  recovery  (retransmission)  following  the  detection  of  a  sequence 

error. 

Only  one  ‘sent  REJ*  exception  condition  from  a  DTE  Of  DCE  is  aablished  at  a  ume.  A  seat  REJ 
exception  condition  is  cleared  when  the  requested  I  frame  is  received. 

A  DTE  or  DCE  receiving  REJ  initiates  sequential  (re*)transmisaion  of  I  frames  surttng  with  the  I  frame 
indicated  by  the  N(R)  obuincd  in  the  REJ  frame. 


2JJ.4  fime-OM/ recov*ir> 

If  a  DTE  or  DCE ,  due  to  a  transmission  error,  does  not  receive  (or  recaves  and  discartb)  a  single  I  -rame 
or  the  last  I  frame  in  a  seq.  rnce  of  I  frames,  it  will  not  detea  an  out-of-sequence  e*aP«on  condition  »nd 
therefore  will  fioi  transmit  REJ.  The  DCE  or  DTE  which  transmitted  the  unacknowledged  I  frame(s)  shall, 
Tta  ^mpSon  of  a  sysu"  sproifiro  Umc^  period  (sro  S  lAil.l  Wow,  uk.  appropriam  «o..ry 
aaion  to  daertfiine  at  which  I  frame  retrs^nsmission  must  begin. 


2JJJ  FCS  trror  <md  mvaiid  fnuiu 


Any  frame  .■ncci.cd  with  an  FCS  error  or  which  U  invilid  (see  »  Il»  /hove)  will  he  discarded  and  no 
aaion  is  uken  as  the  rault  of  that  frame. 


J.6  Rfjec/ioo  condUioK 


A  rejection  condition  is  esublished  upon 
command/response  in  the  control  field,  an  invalid 
LAP  application)  or  an  information  field  which 
accommodated. 


the  receipt  ot  an  error  free  frame  which  contains  an  invalid 
frame  format,  an  invalid  N(R)  (however  see  $  2.4.8. 1  below  for 
exceeds  the  maximum  information  field  length  which  can  be 


Ai  the  DTE  or  DCE.  this  exception  condition  is  seponed  by  a  CMDR  (FRMR)  response  for  appropriate 
DCE  or  DTE  action,  respectively.  Once  a  DCE  has  esublUhed  a  CMDR  (FRMR)  exception  condition  no 
additional  I  frames  am  accepted  uptil  the  condidon  is  reset  by  the  DTE  except  lor  examinauon  of  the  P  bu 
(LAPB)  or  examinauon  of  the  P  bit  and  N(R)  (lAP).  The  CMDR  (FRMR)  response  may  be  repealed  «  each 
opfrortuniry  until  recovery  is  effeaed  by  the  DTE  or  undl  die  DCE  initiates  ia  own  recovery. 


2.4  Dtxnpttpm  of  ihk  proetdurts 

14,1  Proetdurt  to  sot  tho  mod*  vchabto  B  fappUcabio  if  both  L4F  and  L4FB  art  tmfhmtmtd) 


The  DCE  will  oiaiatain  an  internal  mode  variable  B,  which  it  will  set  as  follows: 

—  to  I,  upon  acceptance  of  an  SABM  command  front  the  DTE; 

-  to  0.  upon  acccpanctt  of  an  SARM  command  from  the  DTE 

Changes  to  the  mode  variable  B  by  the  DTE  should  occur  only  when  the  link  Kaa  been  disconneaed  as 
desenttd  la  f  14.4J  or  |  lO J  below. 

Should  a  DCE  malfuncsioa  occur,  the  internal  mode  variable  B  will  tw  initially  set  to  I  u|»o  festor^tion 
of  operation,  but  pnor  to  link  set  up  by  the  DTE 

Whenever  B  is  1.  the  DCE  will  use  the  LAPB  link  set-up  and  discoonecdoa  procedures  and  is  said  to  be 
in  the  LAPB  (balanced)  mode. 
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Whenever  B  is  0,  the  DCE  will  use  the  LAP  link  set-up  and  disconnection  procedures  and  is  said  to  be  in 
the  LAP  mode. 

The  following  are  applicable  to  both  LAP  and  LAPB  modes:  H  2.4.2,  2.4J,  2.4.6,  2.4.11. 

The  following  are  applicable  <mly  to  the  LAP  mode:  2.4.4, 14.7, 14J. 

The  following  arc  applicable  only  to  the  LAPB  mode:  {{  14J,  14.9, 14.10. 

14.2  Pfoetdurt  for  addmsmg  (appikatU  to  both  LAP  and  LAPB) 

Frames  containing  commands  transferred  from  the  DCE  to  the  DTE  will  contain  the  address  A. 

Frames  containing  responses  transferred  from  the  DTE  tc  the  DCE  shall  contain  the  address  A. 

Frames  containing  commands  trantierred  from  the  DTE  to  the  DCE  shall  contain  the  address  B. 

Frames  containing  responses  transferred  from  the  DCE  to  the  DTE  will  contain  the  addrms  B. 

A  and  B  addresses  are  codad  as  follows: 

Address  1  2  3  4  S  6  7  S 

A  11000000 

8  10000000 

Note  -  The  DCE  will  discard  all  frames  received  with  an  address  other  than  A  or  B:  the  DTE  should  do 
the  same. 

14J  Procedure  for  dte  use  of  the  P/F  bit  (opplkabU  to  both  LAP  and  LAPB) 

The  PTE  Af  fV'F  $  ^aRM,  SABM,  DISC,  supervisory  command  or  an  I  frame  with  the  P  bit 

set  to  1,  will  set  the  F  bit  to  i  in  the  next  response  frame  it  transmits. 

The  response  frame  returned  bv  the  DCE  to  a  SARM,  SABM  or  DISC  command  with  the  ?  it  set  to  i 
will  be  a  UA  (or  DM)  response  with  the  F  bit  set  to  1.  The  mponsc  frame  recunned  by  the  DCE  to  an  1  frame 
with  the  P  bit  sec  to  1  will  be  an  RR,  REJ,  RNR.  er  CMDR  (FRMR)  response  format  with  the  F  bit  set  to  I. 

The  response  frame  returned  by  the  DCE  to  a  supervisory  command  frame  with  the  P  bit  set  to  I  will  be 
an  RR.  RNR.  or  CMDR  (FRMR)  rmponse  with  the  F  bit  set  to  1. 

The  P  bit  may  be  used  by  the  DCE  in  conjuncaon  with  the  timer  recovery  condition  (see  1 14.6.S  below). 

Note  -  Other  uk  of  the  P  bit  by  the  DCE  is  a  subject  for  further  snidy. 


14.4  Procedures  for  limk  semp  omd  diseomueaiom  (eppHembk  to  LAP) 

14.4.1  Lmk  set-up 

The  DCE  will  indicate  that  it  is  able  lu  set  up  the  link  by  transmiitisg  contiguous  flags  (active  channel 

autek 

The  DTE  shall  iadicau  a  request  for  seniag  up  the  link  by  trmasmittiag  ■  SARM  command  to  the  DCE. 

Wbeaever  receiving  a  SARM  command,  the  DCE  will  return  a  UA  rmpoasc  to  the  DTE  and  set  «u  leonvc 
atase  variable  V(R)  to  0. 

Should  the  DCE  wish  to  isdicau  a  request  for  setting  op  the  link,  or  aAcr  transmission  of  ■  UA  response 
to  a  flrw  SAR.M  command  from  the  DTE  as  a  request  for  letung  up  the  link,  the  DCE  will  crsasmit  a  SARM 
command  to  the  DTE  aad  aurt  Timer  Tl  (see  1 14.1 1.1  below).  The  DTE  will  confirm  the  reception  of  the  SARM 
command  by  transmitting  a  UA  response.  When  receiving  the  UA  response  the  DCE  art  I  set  its  send  aau 
variebie  to  0  aad  stop  its  TUncr  Tl. 

If  TlaMT  Tl  runs  out  before  the  UA  rmponse  is  reoaved  by  the  DCE.  ta*  DCE  will  rctraasmtt  a  SARM 
command  and  resart  Timer  Tl.  AAer  trmasmitaioo  of  SARM  N2  tunes  by  the  DCE,  appropnaic  recovery  action 
wdl  be  inineied 

The  value  of  N2  is  defined  in  1 14.1 1 J  below. 
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14A2  Information  transfer  phase 

After  having  both  received  a  UA  response  to  a  SARM  command  transmitted  to  the  DTE  and  transmitted  a 
UA  response  to  a  SARM  command  received  from  the  DTE.  the  DCE  will  accept  and  transmit  I  and  S  frames 
according  to  the  procedures  described  in  {  14.6  below. 

When  receiving  a  SARM  command,  the  DCE  will  conform  to  the  resetting  procedure  described  in  J  14.7 
below.  The  DTE  may  also  receive  a  SARM  command  according  to  this  resening  procedure. 


14.4J  Unk  disconnection 

During  the  information  transfer  phase  the  DTE  shall  indicate  a  request  for  disconnecting  the  link  by 
transmitting  a  DISC  command  to  the  DCE 

Whenever  receiving  a  DISC  command,  the  DCE  will  return  a  UA  response  to  the  DTE 

During  an  information  transfer  phase,  should  the  DCE  wish  to  indicau  a  request  for  disconnecting  the 
link,  or  when  receiving  from  the  DTE  a  first  DISC  command  as  a  request  for  disconnecting  the  link,  the  DCE 
will  transmit  a  DISC  command  to  the  DTE  and  stait  Timer  T1  (i  14.11.1  below).  The  DTE  will  confirm 
reception  of  the  DISC  command  by  returning  a  UA  response.  After  transmitting  a  SARM  command,  the  DCE 
will  not  transmit  a  DISC  command  until  a  UA  response  is  received  for  this  SARM  command  or  until  Timer  T1 
ru.tts  out  When  receiving  a  UA  response  to  the  DISC  command,  the  DCE  will  stop  its  Timer  Tl. 

If  Timer  Tl  runs  out  before  a  UA  response  is  received  by  the  DCE  the  DCE  will  retransmit  a  DISC 
command  and  restart  Timer  Tl.  After  transmission  of  DISC  N2  times  by  the  DCE  appropriate  recovery  action 
will  be  initieted.  The  value  of  N2  is  defined  in  1 14.1  U  below. 


14i  Procedura /or  link  set-up  and  disconnection  (appiicabie  to  LAPB) 

14J.1  Link  set-up 

Toe  EX:E  will  inukaic  wiZ  i:  U  at?5  to  ms  up  the  'ink  by  trasisinisg  contiguou*  Hags  (active  channel 

state). 

Whenever  receiving  an  SABM  command,  the  DCE  will  recuro  a  UA  response  to  the  DTE  and  set  both  its 
send  and  receive  state  variables  V(S)  and  V(R)  to  0. 

Should  the  DCE  wish  to  sss  up  the  link,  it  will  send  the  SABM  command  and  start  Timer  Tl  (set 
1 14.11.1  below).  Upon  reception  of  the  UA  response  from  the  DTE  the  DCE  rescu  both  its  send  and  receive 
state  variables  V<S)  and  V(R)  to  0  an  ‘  stops  its  T^cr  Tl. 

Should  Timer  Tl  expire  before  reopen  of  the  UA  response  from  the  DTE  the  DCE  will  retransmit  the 
SABM  command  and  restart  Timer  Tl.  After  transmission  of  the  SABM  comraasd  N2  times  by  the  DCE 
appropriate  recovery  action  will  be  initialed.  The  value  of  N2  is  defined  in  |  14.11.2  below. 


14J.2  Informa’non  transfer  phase 

After  having  transmitted  the  UA  response  to  an  SABM  comnued  or  havin|  received  the  UA  response  to  a 
transmiaed  SABM  command,  the  DCE  will  accept  and  transmit  I  and  S  frames  according  to  the  procedures 
described  in  f  14.6  bdo  v. 

When  receivittg  an  SAB.M  command  whik  in  the  isformsrica  transfrjr  phase,  the  DCE  will  conform  to  the 
resecting  procedure  described  in  |  14.9  below. 

14.5  J  Unk  dbe.mnectiom 

During  the  infonnanon  transfer  phesc.  the  DTE  shall  indicant  disconnecring  of  the  link  by  trmnimitting  a 
DISC  command  to  rhe  DCE 

When  rccriving  a  DISC  ooiuiaad,  the  DCE  will  mum  a  UA  response  to  the  DTE  and  enter  the 
disoonnccted  phase. 

Should  the  DCE  wish  to  dlsconaca  the  link,  it  will  send  the  DISC  oommaad  and  start  Timer  Tl  (see 
I  14.1  l.i  bdow).  Upon  recepdoa  of  the  UA  response  from  the  DTE  the  DCE  will  nop  its  Timer  Tl. 

Shoeld  Timer  Tl  expire  before  recepdoa  of  the  UA  response  frost  the  DTE  the  DCE  will  resranxmit  the 
DISC  oossand  tad  rmart  Timer  Tl.  After  traosmtssioo  of  the  DISC  command  N2  baes  by  the  DCE 
appropnam  recovery  accioo  w.U  be  iaidated.  Ihe  va]«w  of  N2  is  defined  in  |  lAlU  below. 
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14^.4  Diseonntaed  phase 

14J.4.I  After  having  received  a  DISC  command  from  the  DTE  and  returned  a  UA  responM  to  the  DTE,  or 
having  received  the  UA  response  to  a  transmitted  DISC  command,  the  EXTE  will  enter  the  disconnsoed  phase. 

In  the  disconnected  phase,  the  DCE  may  initiate  link  set-up.  In  the  disconnected  phase,  the  DCE  will 
react  to  the  receipt  cf  an  SABM  command  as  described  in  1 14J.]  above  and  will  transmit  a  DM  response  in 
answer  to  a  received  DISC  command. 

When  lecesving  any  other  command  frame  with  the  P  bit  set  to  I,  the  DCE  will  transmit  a  DM  response 
with  the  F  bit  set  to  1. 

Other  frames  received  in  the  diaoonweted  phase  will  be  ignored  by  the  DCE 

14i.4J  When  the  DCE  entfer<(  the  disconnected  phase  after  deteoing  error  conditions  as  listed  in  9  14.10  below, 
or  exceptionally  after  recovery  from  an  internal  temporary  malfunction:  it  may  also  indicate  this  by  sending  a 
DM  response  rather  than  a  DISC  oimrn/ind.  In  these  cases,  the  DCE  will  transmit  DM  and  surt  iu  Timer  TI  (see 

1 14.11.1  below). 

If  Timer  TI  runs  out  before  the  reception  of  an  SABM  or  DISC  command  from  the  DTE  the  DCE  will 
retransmit  the  DM  response  and  rcstirt  Timer  TI.  After  transmission  of  the  DM  response  N2  times,  the  DCE  will 
remain  in  the  disconnected  phase  and  appropriate  recovery  actions  will  be  initiated.  The  value  of  N2  is  defined  in 

1 14.1  U  below. 


14J  J  Collmtm  of  unnumhered  commands 

Collision  situations  shall  be  resolved  in  the  following  way: 

14JJ.I  If  the  sent  and  received  U  commands  arc  the  same,  the  DTE  and  DCE  shall  send  the  UA  response  at  the 
earliest  possible  oppor.unity.  The  DCE  shall  enter  the  indicated  phase  after  receiving  the  UA  response. 

14JJ.2  If  the  sent  end  received  U  commands  arc  different,  the  DTE  and  DCE  shall  enter  the  disconneaed  phase 
and  issue  a  DM  response  at  the  earliest  possible  opportunity. 

14J.6  CoUision  of  DM  response  wuh  the  SABM  or  DISC  commands 

Wb«i  a  DM  response  is  issued  by  the  DCE  as  an  unsolicited  response  to  request  the  DTE  to  issue  a 
mode-seniitg  command  as  described  in  1 14J.A1  a  collision  between  a  SABM  or  DISC  command  imued  by  the 
DTE  and  the  unsolidted  DM  response  issued  by  the  DCE  may  occur.  In  order  to  avoid  misinterpretation  of  the 
DM  received,  it  is  suggested  that  the  DTE  always  send  its  SABM  or  DISC  command  with  the  P  bir  set  to  1. 


14.6  hoceditra  for  information  transfer  (applicable  to  both  LAB  and  L4FB) 

Tbe  procedures  which  apply  u>  the  trantmissioa  of  1  frames  in  each  direction  during  the  information 
transfer  phase  are  described  bdow. 

In  the  following,  "number  1  higher"  is  in  reference  to  a  coniinuously  repeated  sft^ence  series,  i.«^  7  is 
1  higher  than  6  and  0  is  1  higher  than  7  for  modulo  t  scries. 

14.6.1  Sanding  !  ^mmes 

When  the  DCE  has  an  I  frame  to  transmit  (le.,  an  I  frame  not  already  transmined,  or  having  to  be 
faSTaesmmed  as  described  in  ||  14.6J  or  14.6J  bdow).  it  will  transmit  it  with  an  N(S)  equal  to  iu  cuneni  send 
emu  vartabk  V(S).  and  an  N(R)  equal  to  iu  current  receive  state  variable  V(R).  At  the  end  of  the  transmission  of 
the  1  frame,  it  will  increment  iu  sc^  smte  variable  V(S)  by  1. 

If  Timer  TI  is  not  ronning  at  the  instant  of  transmission  of  an  I  frame,  it  wiU  be  lUftad. 

If  the  send  sure  variable  V(S)  is  equal  to  the  Iasi  value  of  N(R)  received  plus  k  (wbere  k  is  the  maximum 
number  M  outstanding  1  fremm  •  sec  |  14.11.4  bdow),  the  DCE  will  not  transmit  any  new  1  frames,  bui  may 
retransmit  an  1  frame  as  described  in  |  14AJ  or  |  14.6J  bdow. 

Hate  -  le  order  to  ensure  security  of  informatioo  transfer,  the  DTE  should  not  uansmii  any  new  1  frame 
if  IU  and  suu  variable  V(S)  is  equal  to  the  last  value  of  N(R)  it  has  received  from  the  DCE  plus  7. 
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When  the  DCE  is  in  the  busy  condition  it  may  still  transmit  I  frames,  provided  that  the  DTE  is  not  busy 
itself.  When  the  DCE  is  in  the  command  rejection  condition  (LAP),  it  may  still  transmit  I  frames.  When  the  DCE 
is  in  the  frame  rejeaion  condition  (LAPS),  it  will  stop  transmitting  I  frames. 


2.4.6.2  Rectivinf  an  t  frame 


14.6.2.1  When  the  DCE  is  not  in  a  busy  condition  and  receives  with  the  correct  PCS  an  t  frame  whose  send 
sequence  number  is  equal  to  the  DCE  receive  sute  variable  V(R),  the  DCE  will  accept  the  information  field  of 
this  frame,  increment  by  I  iu  receive  sute  variable  V(R),  and  act  as  follows; 

i)  If  an  I  frame  is  available  for  transmission  by  the  DCE,  it  may  ao  as  in  }  14.6.1  above  and 
acknowledge  the  received  I  fume  by  setting  N(R)  in  the  control  field  of  the  next  transmitted  I  frame 
to  the  value  of  the  DCE  receive  sute  variable  V(R>.  Aitemativeiy,  the  DCE  may  acknowledge  the 
received  I  frame  by  transmining  an  RR  with  the  N(R)  equal  to  the  value  of  the  DCE  receive  sute 
variable  V(R). 

ii)  If  no  I  frame  is  available  for  transmission  by  the  DCE,  it  will  transmit  an  RR  withi  the  N(R)  equal  to 
the  value  of  the  DCE  receive  sute  variable  V(R). 

2.4  6.2.2  When  the  DCE  is  in  a  busy  condition,  it  may  ignore  the  information  field  conuined  in  any  received 
i  frame. 

Note  -  Zero  length  information  fields  shall  not  be  passed  to  the  packet  level  and  this  siniation  should  be 
indicated  to  the  packet  level. 


2.4.6.3  Reception  of  incorrect  frames 


When  the  DCE  receives  a  frame  with  an  incorrect  PCS  or  receives  an  invalid  frame  (see  |  119),  this 
frame  will  be  discarded. 

When  the  DCE  receives  an  I  frame  whose  PCS  is  correct,  but  whose  send  sequence  number  is  incorrect, 
i.e..  not  equal  to  the  current  DCE  receive  sute  variable  V(R).  it  will  discard  the  infonnaxion  field  of  the  frame 
and  transmit  an  REJ  response  with  the  N(R)  set  to  one  higher  than  the  N(S)  of  the  last  correctly  received  I  frame. 
The  DCE  will  then  discard  the  information  field  of  all  I  frames  until  the  expeaed  I  frame  is  correctly  received. 
When  receiving  the  expeaed  I  frame,  the  DCE  will  then  acknowledge  the  frame  as  described  in  |  14.61  above. 
The  DCE  will  use  (he  N(R)  and  P  bit  indicaaons  in  the  discarded  I  frames. 


2.4.6.4  Recetvint  acknowledgement 


When  receiving  correaly  an  I  or  S  frame  (RR.  RNR  or  REJ).  even  in  the  bu;iy  or  command  rejeaion 
condition,  the  DCE  will  consider  the  N'R)  contained  in  this  frame  as  an  acknowledgement  for  all  the  I  fram<n  it 
has  transmitted  with  an  N(S)  up  to  and  including  the  received  N(R)  minus  one.  The  DCE  will  reset  the  Timer  T1 
when  It  receives  correaly  an  I  or  S  frame  with  the  N(R)  higher  than  the  last  received  N(R)  (aaually  ackrowl- 
edging  some  I  framesL 

If  Timer  TI  has  been  reset,  and  if  there  are  ouuunding  I  frames  still  unacknowledged,  the  DCE  will 
resurt  Timer  TI.  If  Timer  Tl  (hen  runs  out,  (he  DCE  will  follow  the  rctransiB4saMn  fnoccdure  (in  }  14,6.5  and 
)  2.4  6.8  bdow)  with  respea  to  (he  unacknowledged  I  frames. 


14  6  5  Recttnng  rejea 


When  receiving  an  REJ.  the  DCE  will  set  lU  send  sute  vanable  V(S)  to  the  value  of  (he  N(R)  received  in 
the  REJ  control  field  it  will  transmit  the  corresponding  I  frame  as  soon  u  it  is  available  or  retransmit  it 
(ReKransmission  will  conform  to  the  following: 

i)  If  (he  DCE  is  trarumining  a  supervisory  or  unnumbered  command  or  response  when  it  reemves  the 
REJ.  It  will  complete  that  transmission  before  commenang  transmiasioa  of  the  requested  I  frame. 

Ill  If  the  DCE  IS  transmitung  an  I  frame  when  the  REJ  is  received,  it  may  abort  (be  I  frame  and 
commence  transmission  of  the  requested  I  frame  immediately  after  abortioa. 
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iii)  If  the  DCE  is  not  transraittini  tny  frame  when  the  REI  is  received,  it  will  commence  transmission  of 
the  requested  I  frame  immediately. 

In  all  cam,  if  ocher  unacknowledged  1  frames  have  already  been  transmitted  followinf  the  one  indicated 
in  the  REJ,  then  those  I  fram«  will  be  retransmitted  by  the  DCE  following  the  retransmiuion  of  the  requested 
I  frame. 

If  the  REJ  frame  was  received  from  the  DTE  as  a  command  with  the  P  bit  set  to  1.  the  DCE  will  transmit 
an  RR  or  RNR  response  with  the  F  bh  set  to  1  before  transmitting  or  retransmitting  the  corresponding  !  frame. 


14.6.6  Recenutg  RNR 


After  receiving  an  RNR,  the  DCE  may  transmit  or  retransmit  the  I  frame  with  the  send  sequence  number 
equal  to  the  N(R)  indicated  in  the  RNR.  If  Timer  T1  runs  out  after  the  reception  of  RNR,  the  DCE  will  follow 
the  procedure  described  in  §  14.6.1  below.  In  any  case  the  DCE  will  not  fransmit  any  other  1  frames  before 
receiving  an  RR  or  REJ. 


14.6.7  DCE  busy  eomdition 

When  the  DCE  enters  a  busy  condition,  it  will  transmit  an  RNR  respoMC  ti  the  eariiest  opportunity. 
While  in  the  busy  condition,  the  DCE  will  accept  and  process  S  frames  and  return  an  RNR  response  with  the 
F  bit  set  to  1  if  it  receives  an  S  or  1  command  frame  with  the  P  bit  set  to  1.  To  dear  the  busy  condiuon,  the  DCE 
will  transmit  either  an  REJ  response  or  an  RR  rwponse  with  N(R)  set  to  the  current  receive  state  variable  V(R) 
depending  on  whether  or  not  it  discarded  information  fields  of  correctly  received  I  frames. 

Note  -  The  DTE  when  encountering  a  DCE  busy  condition,  may  send  supervisory  command  frames  with 
the  P  bit  set  to  1.  In  the  event  that  the  DTE  has  not  implemented  supervisory  commands,  it  may  follow  the 
procedures  of  the  DCE  (see  f  14.6.6)  (applicable  to  LAPB). 


14.6.S  Wmtmg  aeknowUdgtmsnt 


The  DCE  maintains  an  internal  retransmission  count  variable  which  is  set  to  0  when  the  DCE  receives 
a  UA  or  RNR,  or  when  the  DCE  receives  correctly  an  1  or  S  frame  with  the  N(R)  higher  than  the  last  received 
N(R)  (actually  acknowledging  some  outstanding  1  frames). 

If  Timer  T1  runt  out,  the  DCE  will  (re-)enter  the  timer  recovery  condition,  add  one  to  iu  retransmiuion 
count  variable  and  set  an  internal  variable  x  to  the  current  value  of  iu  send  statt  variable. 

The  DCE  will  restart  Tuner  T1,  set  its  send  sute  variable  to  the  last  value  of  N(R)  received  from  the  DTE 
and  retransmit  the  cormponding  I  framt  with  the  P  bit  set  to  I  (LAP  or  LAPS)  or  transmit  an  appropriate 
supervisory  command  sriih  the  P  bit  set  to  I  (LAPB  only). 

The  timer  recovery  conditioo  is  deared  when  the  DCE  receives  a  valW  S  frame  from  the  DtE  with  the 
F  bit  set  to  I. 

If  while  in  the  timer  recovery  condiuon.  the  DCE  receivet  correctly  %  lupervrory  frame  with  the  F  bit  set 
to  1  and  with  the  N(R)  wnhin  the  range  from  »  current  send  suu  variable  to  x  inH^idcd,  h  will  dear  the  nmer 
recovery  condition  and  set  lU  tend  sute  variabk  to  the  value  of  the  received  N(R). 

If.  while  in  the  nmer  recovery  condiuon,  the  DCE  veaam  eoneexly  a  supervisory  frame  with  the  F  bit  « 
to  0  and  with  an  N(R)  swihin  the  range  from  iu  current  send  nau  variable  to  x  induded,  it  will  not  dear  the 
nmer  recovery  condiuon.  value  of  the  received  N(R)  may  be  used  to  update  the  send  mate  variable 
the  DCE  may  daade  to  keep  the  last  transmiocd  1  frame  in  nort  (even  if  it  it  scinowledgsd)  in  order  to  be  able 
to  letrmnsmii  it  with  the  P  hit  act  to  I  when  Timer  Tl  runs  out  at  s  later  time. 

If  the  retranwnission  count  variable  it  equal  to  N2.  the  DCE  initiates  s  retening  procedure  for  the 
dirccuon  of  tranimiuion  froei  the  DCE  as  described  in  |  2.4.7J.  |  2.4.9J  or  |  2.4.9J  below.  N.  u  s  system 
parameter  (see  |  14.11  J  bdow). 

Nats  -  Although  the  DCE  will  implement  the  internal  variable  x.  other  mechanisms  do  exist  that  achieve 
the  idcnucal  functions.  Therefore,  the  iiitcmnl  vansbie  x  it  not  necessarily  impicmcntsd  in  the  DTE 
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2.4  92  The  DTE  or  DCE  shall  indicate  a  resetting  by  transmitting  an  SABM  command.  After  receiving  an  SABM 
command,  the  DCE  or  DTE,  respectively,  will  return,  at  the  earliest  opportunity,  a  UA  wponse  to  the  DTCor 
DCE,  respectively,  and  reset  iu  send  and  receive  state  variables  V(S)  arid  V(R)  to  0.  This  also  clears  a  DCE 
and/or  DTE  busy  condition,  if  present  Prior  to  initiating  this  link  resetting  procedure,  the  DTE  or  DCE  may 
initiate  a  disconnect  procedure  as  described  in  {  L4iJ  above. 

14.9 J  Under  certain  rejection  conditions  listed  in  $  14.6.8  above  and  {  14.101  below,  the  DCE  may  ask  the 
DTE  to  reset  the  link  by  transmitting  a  DM  response. 

After  transmitting  a  DM  response,  the  DCE  will  enter  the  disconneaed  phase  as  described  in  {  14.5.41 

above. 

14.9.4  Under  certain  rejection  conditions  listed  in  1 14.10.1  below,  the  DCE  may  ask  the  DTE  to  reset  the  link 
by  trensmitting  an  FRMR  response. 

After  transmitting  an  FRMR  response,  the  DCE  will  enter  the  frame  rejection  condition.  The  frame 
rejection  condition  is  cleared  when  the  DCE  receives  an  SABM  or  DISC  command  or  DM  ^f»nse  Any  other 
command  received  while  in  the  frame  rejection  condition  will  cause  the  DCE  to  retransmit  the  FRMR  response 
with  the  same  information  field  as  originally  transmitted. 

Tne  DCE  may  surt  Timer  T1  on  transmiuien  of  the  FRMR  response.  If  Timer  T1  runt  out  before  the 
reception  of  an  SABM  or  DISC  command  from  the  DTE,  the  DCE  may  retransnit  the  FRMR  respon^  and 
resurt  Timer  Tl.  After  transmiuion  of  the  FRMR  response  N2  times  the  DCE  may  reset  the  link  as  described  in 
I  14.91  above.  The  value  of  N2  is  defined  in  1 14.111  below. 


14.10  Rejtaton  eoiiditioiu  (applicabU  to  LAPS) 


14  :e  1  The  DCE  will  initUte  a  resetting  procedure  as  describ^J  in  1 14=9  4  above,  when  receiving,  during  the 
information  transfer  phase,  a  frame  with  the  correa  FCS,  with  the  address  A  or  B.  and  with  one  of  the  following 
conditions: 

-  the  frame  is  unknown  as  a  oommaiMl  or  as  a  response; 

-  the  information  field  is  invalid: 

-  the  N(R)  contained  in  the  control  field  is  invalid  as  described  in  |  14.1.1  above. 

The  coding  of  the  information  field  of  the  FRMR  response  which  is  transmitted  is  given  in  | 
above.  Bit  13  of  this  information  field  is  set  to  0  if  the  address  of  the  rejected  frame  is  B.  It  is  set  to  I  if  the 
address  is  A. 

14.101  The  DCE  will  initiau  a  resetting  procedure  as  described  in  1 14.91  or  1 14.9J  above  when  receiving 

during  the  information  transfer  pluue  a  DM  response  or  an  FRMR  response. 

The  DCE  may  initiau  a  resetting  procedure  as  describ^  in  1 14.91  or  1 14.9J  above  when  receiving 

dunng  the  information  transfer  phase  a  UA  response  or  an  anaolidted  responu  with  the  F  bit  set  to  1 . 


14.1 1  Lat  of  systrm  pmrmmtttn  (oppiicobk  to  both  LAFomd  L4PB) 
The  lyitem  peraneters  are  as  follows: 


14.11.1  Timor  n 


The  period  of  Timer  Tl  will  take  into  account  whether  the  bmer  is  wuttd  at  the  beginning  or  the  end  of 
the  frame  in  the  DCE. 


The  period  of  Timer  Tl.  at  the  end  of  which  retransmission  of  a  frame  nuy  be  initiated  according  to  the 
procmlures  descnbmi  in  H  2.4  *  to  14  6  above,  is  a  system  parameter  agreed  for  a  penod  of  ume  with  the 
Administrauon. 


The  proper  operation  of  the  procedure  raquirai  that  Timer  Tl  be  greaur  than  the  maximum  time  betwew 
transmission  of  frames  (SARM.  SABM.  DM.  DISC  FRMR,  I  or  supervisory  oommsi»ds)  and 
oonusponding  frame  returned  u  an  answer  to  thu  frame  (UA  DM  or  acknowledging  frame).  Therefore  the  D^ 
should  not  delay  the  response  or  acknowledging  frame  returned  to  the  above  frames  by  more  than  s  value  T2  less 
than  Tl.  where  T2  is  a  syeiem  parameter. 


The  DCE  wUl  net  deUy  the  response  or  acknowledging  frame  returned  i 
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14.7  Proetdum  for  mtitifig  (applicable  to  LAP) 

14.7.1  The  resettini  procedure  is  used  to  reinitialize  one  direction  of  information  transmission,  according  to  the 
procedure  described  below.  The  resetting  procedure  only  applies  during  the  information  transfer  phase. 

14.7.2  The  DTE  will  indicate  a  resetting  of  the  information  tranimiMion  from  the  DTE  by  transmitting  an 
SARM  command  to  the  DCE  When  receiving  an  SARM  command,  the  DCE  will  return,  at  the  earliest 
opportunity,  a  UA  response  to  the  DTE  and  set  iu  receive  lUte  variable  V(R)  to  0.  Thu  also  indicates  a  dearanos 
of  the  DCE  busy  condition,  if  present 

14.7J  The  DCE  will  indicate  a  roetting  of  the  information  transmiuion  from  the  DCE  by  transmittiog  an 
SARM  command  to  the  DTE  and  will  start  Timer  Tl  (see  $  14.11.1  below).  The  DTE  will  confirm  reception  of 
the  SARM  command  by  returning  s  UA  response  to  the  DCE  W'len  receiving  this  UA  response  to  the  SARM 
command,  the  DCE  will  set  iu  send  state  variable  to  Q  and  stop  its  Timer  Tl.  If  Timer  Tl  runs  out  before  the 
UA  response  is  reaived  by  the  DCE  the  DCE  will  retransmit  la  SARM  command  and  restart  Tuner  Tl.  AA» 
transmiuion  of  SARM  N2  times,  appropriate  recovery  action  will  be  initiated.  The  value  of  N2  is  defined  in 
}  14.11.2  below. 

The  DCE  will  not  so  on  any  received  response  frame  which  arrives  before  the  UA  response  to  the  SARM 
command.  The  value  of  N(R)  contained  in  any  corrcoly  received  I  command  frames  arriving  before  the 
UA  response  will  also  be  ignored. 

14.7.4  When  receiving  a  CMDR  response  from  the  DTE  the  DCE  will  initiau  a  resetting  of  the  information 
transmiuion  from  the  EXTE  as  described  in  |  14.7J  dwvc. 

14.7J  If  the  DCE  transmiu  a  CMDR  responat,  it  enten  the  command  rejection  condition.  This  command 
rejection  condition  is  cleared  when  the  DCE  receives  an  SARM  or  DISC  command.  Any  ocher  command  received 
while  in  the  command  rejection  condition  will  causs  the  DCE  to  retransmit  this  CMDR  response.  The  coding  of 
the  CMDR  respone  will  be  as  dcscr/oed  in  |  2J.4.10  above. 


2.4.8  Rejection  conditions  (applicable  to  LAP) 


14.8.1  Rejeaton  conditions  causing  a  raetting  of  the  transmission  •/  information  from  the  DCE 

The  DCE  will  initiate  a  resecting  procedure  as  described  in  f  14.7J  above  when  receiving  a  fraase  wHh  the 
correa  FC.^,  with  the  address  A  (coded  1 1000000)  and  with  one  of  the  following  conditions: 

-  the  frame  type  is  unknown  as  one  of  the  responses  used: 
the  information  field  is  invalid: 

o  the  N(R)  conuined  in  the  control  field  is  tnvaUd: 

-  the  response  contains  an  F  bit  set  to  1  eaerpe  during  a  timer  recovery  condition  as  described  in 
I  14.6J  above. 

The  DCE  will  also  initiau  a  resetting  procedure  as  described  in  |  14.7J  above  when  receiving  an  I  frame 
with  correa  FCS,  with  the  address  I  (coded  10000000)  and  with  an  invalid  N(R)  contained  in  the  control  field. 

A  valid  N(R)  must  be  within  the  range  from  the  lowest  tend  sequence  number  N(S)  of  the  still 
unacknowledged  frame(s)  to  the  current  DCE  send  stau  variable  included,  even  if  the  DCE  is  in  a  rejecnoo 
condtuon.  but  not  if  the  DCE  u  in  the  timer  recovery  condioon  (sne  1 146.1  above). 


2.4 1.2  Rej^xnon  conditions  causimg  the  DCE  se  roguesi  a  resetting  ef  the  irenieuinoe  qf’  mfeemasian  from  the  DTI 

The  DCE  will  enter  the  oommard  rejection  oonditioe  as  described  in  |  14.7J  above  when  recsiviag  a 
frame  with  the  correa  FCS.  with  the  address  I  (coded  tOOOOOOO)  end  with  one  of  the  fedowsag  condttiona: 

•>  the  frame  type  is  unknown  as  one  td  the  oommanda  used; 

-  the  infwmatioe  field  la  invalid. 


14.9  Procedures  for  resetnng  fappheahie  to  LA  Pi) 


14.9  I  The  resetting  prooedum  are  used  lo  iaioaltae  both  direaions  cf  informaiioe  tnnamistion  according  to  the 
procedure  daenbed  below  The  reacinag  prooidurca  onijr  apply  dunng  the  information  irmnsfcr  phase. 
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14.1  U  Maximum  munbar  of  transnussums  N2 

The  value  of  the  maximum  number  N2  of  tranamuaion  and  retranamtaaiona  of  a  frame  followini  the 
ninnmi  out  of  Timer  T1  ia  a  aystem  parameter  agreed  for  a  period  of  time  with  the  Adminiatration. 

14.1 1 J  Maximum  mtmbtr  efikuutam  I  from*  Nl 

The  maximum  i^amber  of  bia  io  an  I  frame  ia  a  ayatem  parameter  which  dcpenda  upon  the  maximum 
length  of  the  infonnatioo  fielda  tranafened  acroe  the  DTE/OCE  interface. 

14.1 1 .4  Maximum  aumbtr  of  outstatMiag  i  k 

The  maximum  number  (k)  of  aequcndally  numbered  I  framca  that  the  DTE  or  DCE  may  have  outstanding 
(i.e..  unacknowledged)  at  any  given  deue  ia  a  ayfiem  parameter  which  cun  never  exceed  aevcn.  It  ahall  be  agreed 
for  a  period  of  dme  with  the  Adminiatradon. 

Non  >  As  a  rewIt  of  the  further  study  propoeed  in  f  114  above,  the  permissible  maximum  number  of 
outstanding  I  frames  may  be  increased. 


3  Description  of  the  pocket  levti  OTE/DCE  interface 

This  and  subsequent  poinu  )f  the  Recomraendadon  relate  to  the  transfer  of  packets  at  the  DTE/DCE 
interface.  The  procedures  apply  to  pa  *Jmiu  which  are  sucocasfuUy  transferred  acrou  the  DTE/DCE  interface. 

Each  pocket  to  be  transferred  aerMs  the  DTE/DCE  interface  shall  be  contained  within  the  link  level 
informadon  field  which  will  delimit  its  length,  and  only  one  pocket  shall  be  contained  ia  the  iaformadoa  field. 

Son  I  »  Possible  inaerdon  of  more  than  one  packet  in  the  link  level  informadon  field  ia  for  further 

study. 

Nan  3  -  At  praaent,  some  networks  require  the  dau  fielda  of  pockos  io  cootain  an  Integral  number  of 
octets.  The  transmiaaion  by  the  DTE  of  dau  fields  not  containing  an  integral  number  of  octeo  to  the  network 
may  cause  a  loss  of  dau  integrity. 

Under  urgent  study  arc  further  oonsidcradons  regarding  the  trends  of  future  requiremenu  and  irapkmenudons 
toward  either  bit-orsentadon  (any  number  of  bits)  or  ocict<oricnuiioe  (an  iniegrti  number  of  octets)  for  dau  fields 
in  X15  packets. 

DTEs  wishing  universal  operadon  on  all  nctworts  should  transmit  all  peckeo  with  dau  fields  conuinini  only  an 
integral  number  of  octcia.  Full  dau  totegrity  can  only  be  assured  by  exchange  of  octet-oriented  dau  fields  ia  both 
dirsetions  of  (rajumissioo. 

This  point  coven  a  dcscripdon  of  the  packet  level  interface  for  virtual  call,  permansnt  virtual  ctreuit  and 
datagram  serviesa.  As  designated  ia  Rcoomraendadoa  X2  (21,  virtual  call  and  permanent  virtual  circuit  servioBS 
are  cssentui  (E)  serviom  to  be  provided  by  alt  neeworka.  Daugram  service  is  designated  as  an  addiuonal 
(A)  service  which  nuy  be  provided  by  some  nerworta. 

Nma  J  -  Under  study  are  coastderadons  regarding  the  amount  of  posaible  duplication  between  daugram. 
fast  selea  and  pouiblc  additional  virtual  call  enhanoemmita  with  the  objective  to  mtnimixe  the  vahciy  of 
mterfaoea. 

Frocndurei  for  the  virtual  dreutt  aervicB  (La.,  vtmul  call  and  permanent  virtual  dreuit  urvicas)  are 
spedfled  in  I  A  Prooedura  for  the  daugram  scrvioe  are  specified  in  f  3.  Packet  fetmeti  for  aM  aerviosa  are 
speafied  in  |  4.  Prooedums  and  fonnma  for  cpoonal  user  fadUdns  are  tpedfled  in  |  7. 


3.1  fefica/  ekammwia 

To  enable  simultaacous  virtual  calls  and/or  permanent  virtual  dreuiu  and/or  dibutrams.  logical  channels 
are  used.  Each  virtual  call,  pemanent  viitnal  circiut,  and  daugnun  citsntK!  b  ssMgncd  a  logical  ensKud  group 
number  (less  than  or  equal  to  15)  and  a  logica!  channd  number  (lem  than  or  equal  to  2SS).  For  vunkd  a 
togical  ckaitnd  group  number  and  a  iOgiol  channel  number  are  aaigned  during  the  call  set-up  phaaa  Tbc  range 
of  logical  channels  used  for  virtus!  oslla  b  agrued  with  the  Adamuuanoa  at  the  ttsM  of  subscnpuoo  le  the 
servtoi  (see  Annex  A).  For  permanent  virtual  orcuits  and  datagram  rhsnnela.  logical  chaaael  group  aumben  and 
logical  channel  aumben  arc  asatgned  ia  afreemeni  wkh  the  Admiaistraaon  at  tbc  time  of  tubeenption  to  the 
ssrher  (sac  Annex  AL 
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L.1  Physical  Requirements 
L.1.1  System  Space 

The  C/30  system  manufactured  by  the  BBN  Computer  Corporation 
(BBN  Computer)  is  available  either  in  a  cabinet  supplied  by  BBN 
Computer,  or  as  parts  that  may  be  installed  in  a  rack  provided  by 
the  customer.  The  requirements  of  these  two  packages  are  very 
different,  as  one  is  completely  self-contained,  and  the  other 
must  have  cooling  and  cable  access  provided  by  the  customer. 
Many  of  the  specifications  are  therefore  different,  and  should  be 
carefully  noted.  We  recommend  that  all  machines  be  ordered  with 
cabinets  to  minimize  potential  operational  and  maintenance 
problems . 

L.1. 1.1  C/30  Systems  in  BBN  Computer  Cabinets 

The  enclosure  for  the  C/30  system  is  62  inches  high,  25 
inches  wide,  and  36  inches  deep.  With  the  rear  door  opened,  the 
depth  increases  to  55  inches.  To  allow  for  service  to  the 
system,  an  additional  space  of  36  inches  should  be  provided 
surrounding  the  entire  cabinet.  Note  that  up  to  four  enclosures 
may  be  placed  side  by  side  before  a  36  inch  service  space  is 
required  between  cabinets. 

L.1. 1.2  C/30  Systems  in  Customer  Provided  Cabinets 

The  C/30  systems  are  also  available  as  parts  that  are  to  be 
installed  in  a  customer  provided  cabinet.  Three  distinct  pieces 
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will  always  be  included:  the  power  supply/card  cage  assembly,  the 
microcassette  drive,  and  the  cable  fantail  assemblies.  In 
addition,  the  system  may  be  purchased  with  an  Uninterruptable 
Power  Supply  (UPS). 

The  power  supply/card  cage  assembly  size  is  determined  by 
the  type  and  size  of  the  system  purchased.  The  small  C/30 
systems  have  a  power  supply/card  cage  assembly  which  is  12”  high, 
17"  wide,  and  22"  deep,  with  a  face  plate  that  is  12.25"  high  and 
19"  wide.  The  large  C/30  systems  have  a  power  supply/card  cage 
assembly  which  is  19"  high,  17"  wide,  and  22"  deep,  with  a 
faceplate  that  is  19.25"  high  and  19"  wide.  Consult  with  BBN 
Computer  Field  Service  for  the  precise  information  about  the  C/30 
system  purchased. 

The  microcassette  drive  should  be  mounted  either  directly 
above  or  below  the  power  supply/card  cage  assembly.  This  tape 
drive  is  5”  high,  17"  wide,  and  7"  deep,  with  a  faceplate  that  is 
5.25"  high  and  19"  wide. 

Inside  the  cabinet  at  the  rear,  and  either  above  or  below 
the  power  supply/card  cage  assembly,  are  the  best  positions  to 
mount  the  fantail  assemblies.  The  number  of  fantail  assemblies 
is  determined  by  the  number  and  type  of  terminals  to  be  connected 
to  the  system  (1/2  fantail  for  each  type  of  terminal  -  current 
loop,  RS-232,  or  modem  ••  and  1/2  fantail  for  each  increment  of 
eight  terminals  of  the  same  type) ,  plus  one  short  fantail  for  the 
IMP  or  TIP  systems.  The  terminal  fantails  are  5.25"  high  by  19" 
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wide,  and  require  about  2”  of  clearance  on  either  side  (front  and 
back)  for  cable  access.  The  short  fantail  for  the  IMP  or  TIP  is 
3.5”  high  and  19”  wide,  but  will  require  about  4”  of  clearance  on 
either  side  for  cable  access.  All  of  the  cables  tnat  connect  the 
fantails  to  the  interface  controller  in  the  card  cage  are  about 
6’  long,  but  up  to  14”  of  cable  length  may  be  lost  depending  upon 
where  on  the  interface  controller  the  cable  must  reach. 
Therefore,  each  fantail  should  not  be  mounted  more  than  4’  from 
the  power  supply/card  cage,  and  closer  if  this  is  possible. 
However,  no  fantails  may  ever  be  mounted  directly  behind  the  card 
cage,  as  this  would  seriously  hamper  any  field  service  or 
maintenance  to  the  system.  Also,  all  cables  must  be  dressed  back 
to  either  side  of  the  cabinet  to  allow  free  access  to  the  card 
cage,  and  to  insure  better  ventilation. 

The  Uninterruptable  Power  Supply  option  should  be  installed 
in  the  bottom  of  the  cabinet,  or  on  the  floor  very  near  the 
cabinet.  The  UPS  is  10.5”  high,  12”  wide,  and  19"  deep.  All  of 
the  power  connections  are  on  the  front  face  of  the  UPS,  so  the 
unit  should  be  installed  facing  the  rear  door  of  the  cabinet. 

L.  1 .2  Floor  Type 

Although  a  single  C/30  system  does  not  occupy  much  floor 
space.  It  can  have  large  numbers  of  cables  for  connections  to  the 
system  terminals.  The  best  way  of  routing  these  cables  is  under 
a  raised  floor,  which  is  also  the  safest,  as  no  cables  will  be 
above  the  floor  to  trip  the  operators  or  other  personnel.  The 
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raised  floor  may  be  of  either  the  pedestal  type  or  the  raceway 
type,  but  the  pedestal  type  offers  the  most  flexibility  for 
present  and  future  system  layout.  The  floor  should  be  raised 
about  12"  from  the  permanent  floor,  but  this  height  may  be 
changed  by  either  the  flooring  contractor  or  the  air  conditioning 
personnel,  if  the  air  ducts  are  to  be  installed  under  the  floor. 
Any  openings  in  the  floor  should  be  protected  from  debris  which 
might  fall  into  them,  either  by  covers,  screens,  or  the  system, 
and  the  openings  should  have  smooth  edges  so  as  not  to  damage  the 
cables.  Cable  access  holes  directly  underneath  the  systems  are 
the  most  useful,  as  each  BBN  Computer  cabinet  has  a  6"  by  8"  hole 
in  the  bottom  to  allow  cables  to  enter  and  leave. 

Most  importantly,  the  floor  must  be  capable  of  supporting 
the  weight  of  the  system,  which  for  the  C/30  in  BBN  Computer 
cabinets  is  about  190  pounds  (S6Kg.). 

L.1.3  Doorways 

All  of  the  doorways  between  the  computer  room  and  the 
loading  dock  must  be  checked  to  Insure  sufficient  clearance  to 
move  the  system  into  the  computer  room.  Tf  the  C/30  system  is  to 
be  installed  in  a  customer  supplied  cabinet,  all  the  boxes  will 
be  less  than  36"  in  any  dimension.  The  C/30  with  a  BBN  Computer 
cabinet  has  a  shipping  size  of  not  more  than  71"  high,  33"  wide, 
and  UU"  deep.  The  cabinet  is  provided  on  a  pallet  wS*;lch  may  be 
moved,  but  carefully,  with  a  fork  lift  or  pallet  mover.  If  the 
shipping  case  must  be  removed  from  the  cabinet  before  moving  it 
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(to  ff.t  through  all  of  the  doorways),  the  cabinet  may  be  moved 
with  a  :’olly  set  under  either  side,  but  not  under  the  front  or 
rear . 


L.2  Power  Requirements 
L.2.1  AC  Voltage 

The  standard  input  voltage  that  is  required  by  the  C/30  is 
115VAC  with  no  more  than  10%  variation  high  or  low.  When 
required,  the  system  can  be  reconfigured  for  an  input  voltage  of 
220VAC,  >-10%.  In  either  case,  the  voltage  provided  must  be 

single  phase,  grounded  at  the  circuit  box  to  either  the  building 
or  another  large  metal  surface.  If  the  voltage  is  115VAC  the 
receptacle  should  be  NEMA  L5-30R;  if  the  voltage  is  220VAC,  the 
receptacle  should  be  NEMA  L6-20R.  (These  receptacles  are 
necessary  only  if  the  system  is  in  a  BBN  cabinet.  If  the  C/30  is 
installed  in  a  customer  provided  cabinet,  a  standard  3-wire 
receptacle  (NEMA  5-15R  $n5VAC,  or  NEMA  6-15P  (P220VAC)  is 

sufficent  for  either  the  C/30  or  the  UPS.) 

L.2. 2  AC  Current 


The  C/30  system  in  a  BBN  Computer  cabinet  is  provided  with  a 
single  Power  Distribution  Box  which  is  rated  to  30  Amps  at 
115VAC,  and  to  20  Amps  at  220VAC.  The  plug  on  the  Power 
Distribution  Box  for  nSVAC  is  NEMA  L5-30P  (30  Amps,  125  Volt, 
twist-lock) .  The  Power  Distribution  Box  for  220VAC  has  a  NEMA 
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L6-20P  plug  (20  Amps,  250  Volts,  twist-lock).  Each  system  must 
have  a  dedicated  circuit  breaker  of  the  proper  rating  for  the 
voltage  used. 

The  C/30  system  which  is  supplied  for  a  customer  provided 
cabinet  will  not  be  supplied  with  a  Power  Distribution  Box. 
Instead,  the  system  should  be  connected  to  the  customer’s  cabinet 
power  distribution,  or  directly  into  a  wall  (or  floor)  power 
receptacle.  If  the  system  is  supplied  with  an  Uninterruptable 
Power  Supply,  the  system  will  be  connected  to  the  UPS,  and  then 
the  UPS  plugged  into  the  power  source.  The  current  requirements 
of  the  C/30  without  UPS  are  6  Amperes  at  115VAC  (3  Amps  at 
220VAC) ,  and  with  the  UPS  the  current  will  be  3  Amperes  at  nOVAC 
(U  Amps  at  220VAC) . 

L.2.3  AC  Frequency 

The  systems  and  all  of  the  peripherals  standardly  require  50 
Hertz  AC  power,  with  a  tolerance  of  ♦-15.  If  requested,  the 
system  can  be  reconfigured  to  use  50  Hertz  AC  power  (220V  only), 
also  with  a  tolerance  of  ♦-I.OS.  In  either  case,  loss  of  power 
for  less  than  one  cycle  is  tolerated  by  the  internal  power 
supplies.  Loss  of  power  for  more  than  one  cycle  will  cause  a 
system  reboot.  If  the  system  has  an  Uninterruptable  Power 
Supply,  any  loss  of  power  for  up  to  10  minutes  will  be  masked  and 
the  system  will  continue  to  operate. 
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L.2.U  Grounding 

All  power  outlets  for  the  systems  or  the  peripherals  must  be 
three-wire,  grounded  outlets.  The  ground  wires  should  run  back 
to  the  circuit  box  without  interruption,  and  there  be  tied  to  the 
metal  frame  of  the  building,  or  to  a  large  metal  grounding  plate. 
C/30  systems  in  3BN  Computer  cabinets  have  a  ground  bar  inside 
the  cabinet  to  which  the  system  power  supply,  the  cassette  drive, 
and  the  Power  Distribution  Box  are  connected.  These  connections 
are  to  the  AC  Ground  of  each  unit,  except  for  the  system  power 
supply,  where  the  AC  and  DC  grounds  are  tied  together. 

For  C/30  systems  which  are  installed  in  customer  supplied 
cabinets,  the  ground  bar  must  also  be  supplied  by  the  customer. 
The  system  power  supply  has  a  ground  point  marked  on  the  rear  of 
the  supply,  near  the  circui**.  breaker,  which  should  be  connected 
to  the  ground  bar  with  12  awg  wire.  On  the  raicrocassette  drive, 
the  recommended  ground  point  is  the  bolt  on  the  power  supply 
transformer  which  is  connected  to  the  ground  of  the  transformer. 
This  should  be  connected  to  the  cabinet  ground  bar  with  12  awg 
wire.  The  interface  cable  from  the  system  to  the  cassette  has  a 
ground  wire  which  must  be  connected  to  the  nearest  screw  which  is 
used  to  fasten  the  cassette  controller  to  the  chasis.  No 
additional  grounding  connection  is  required  for  the 
Uninterruptable  Power  Supply  option. 
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L.3  Environmental  Requirements 

L.3.1  C/30  Systems  in  BBN  Computer  Cabinets 

L.3. 1.1  Ambient  Temperature  and  Power  Dissipation 

The  room  in  which  the  system  is  running  should  be  maintained 
between  16  and  25  degrees  C  (60-77  F) ,  with  temperature  changes 
of  no  greater  than  4  degrees  C  (7  F)  per  hour.  The  small  system 
and  microcassette  drive  produce  about  II90  Btu/hr  (350  watts); 
the  large  system  and  cassette  drive  produce  about  2220  Btu/hr 
(650  watts).  With  the  Uninterruptable  Power  Supply  option,  the 
small  system  produces  about  2190  Btu/hr  (640  watts);  the  large 
system  produces  about  3220  Btu/hr  (940  watts) .  If  the  system 
console  is  a  video  terminal,  it  produces  about  390  Btu/hr  (115 
watts);  if  the  console  is  a  hard  copy  terminal,  it  produces  about 
15  Btu/hr  (46  watts) . 

Storage  temperature  for  both  the  system  and  the  console  may 
range  from  0  to  45  degrees  C  (32-113  F) . 

L.3. 1.2  Humidity 

The  humidity  of  the  system  room  must  be  between  30)1  and  305, 
with  no  condensation. 

The  storage  humidity  for  the  syotea,  not  including  the 
cassette  tapes,  is  105  to  905,  non-condensing.  See  Section  4.2 
for  storage  information  on  the  cassette  tapes. 
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L.3.1.3  Air  Flow 

The  C/30  system  does  not  require  any  special  air  flow  past 
the  cabinet,  as  long  as  the  system  room  is  within  the  ambient 
temperature  range.  The  system  is  provided  with  its  own  flushing 
fan  which  will  draw  air  into  the  system  from  the  back  door. 

L.3.2  C/30  Systems  in  Customer  Provided  Cabinets 

L.3.2.1  Ambient  Temperature  and  Power  Dissipation 

The  air  immediately  surrounding  the  power  supply/card  cage, 
mic-o-cassette  drive,  system  console,  and  UPS  (if  ordered)  should 
remain  between  16  and  25  degrees  C  (60-77  F) .  The  small  system 
and  cassette  drive  together  produce  about  1190  Btu/hr  (350 
watts);  the  large  system  and  cassette  drive  produce  about  2220 
Btu/hr  (650  watts).  A  video  console  products  about  390  Btu/hr 
(115  watts),  and  a  hard  copy  terminal  produces  155  Btu/hr  (46 
watts).  A  system  with  the  UPS  option  produces  an  additional  1000 
Btu/hr  (290  watts). 

The  storage  temperature  for  the  system,  UPS,  and 
microcassette  drive  is  0  to  45  degrees  C  (32-113  F‘)  • 

L. 3.2.2  Humidity 

The  humidity  of  the  air  surrounding  the  system  must  remain 
between  30t  and  805,  non-condensing. 
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The  storage  humidity  of  the  system,  excluding  the  cassette 
tapes,  is  10%  to  90%,  also  with  no  condensation. 

L.3.2.3  Air  Flow 

Flushing  fans  must  be  provided  in  the  Customer  provided 
cabinet  to  keep  the  internal  cabinet  temperature  within  the 
proper  range.  These  fans  will  need  to  be  larger  if  the  sy'»tem 
has  the  UPS  option,,  if  the  UPS  is  installed  in  the  bottom  of  the 
same  cabinet.  Cabling  from  the  system  to  the  fantails  should 
also  be  consiaered  when  designing  the  flushing  fans,  as  the 
cables  may  impede  the  airflow  around  the  power  supply/card  cage 
assembly. 

L.4  Customer  Supplied  Parts 

L.4.1  Terminal,  Modem,  and  Host  Cables 

The  C/30  systems  are  provided  with  cable  fantails,  up  to  15 
ports  per  fantail  assembly  from  the  asynchronous  multiplexers, 
and  up  to  16  ports  per  fantail  assembly  from  the  synchronous 
modems  and  hosts.  Cables  between  the  fantail  ports  and  the 
terminals  or  modems  may  be  purchased  from  BBH  Computer,  or  may  be 
provided  by  the  customer.  The  cables  from  the  fantail  ports  to 
the  distant  host  must  be  provided  by  the  customer. 

The  following  sections  list  the  cable  pinouts  of  the 
connectors  of  each  fantail  port. 
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L.4.1.1  RS-232  Cable  Connector  (with  BBNCC  Model  5423) 

This  connector  is  for  either  RS-232C  terminals  or  modems. 
It  is  part  of  the  FPT  fantail,  and  is  assembled  in  groups  of  8 

ports.  If  a  terminal  is  to  be  connected  to  the  port,  the  cable 

must  be  modified  to  be  a  null  modem  cable.  This  can  be  done  by 
crossing  the  DSR  pin  of  the  fantail  connector  to  the  DTR  pin  of 
the  terminal  connector;  crossing  the  DTR  pin  of  the  fantail 

connector  to  the  DSR  pin  of  the  terminal  connector;  crossing  the 

RTS  pin  of  the  fantail  connector  to  the  DCD  pin  of  the  terminal 

connector;  crossing  the  DCD  pin  of  the  fantail  connector  to  the 
RTS  pin  of  the  terminal  connector;  and  jumpering  pin  4  to  pin  5 

in  each  connector.  If  a  modem  is  to  be  connected  to  the  port, 

all  signals  should  run  straight  through  the  cable  with  no 

crossing  and  no  jumpers. 

pin  1  Ground 

2  Transmitted  Data  (by  system) 

3  Received  Data  (by  system) 

4  Request  To  Send 

6  Data  Set  Ready 

7  Signal  Ground 

3  Data  Carrier  Detect 

9  ♦  VDC 

10  -  VDC 

15  Transmitted  Clock 


17 


Received  Clock 
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20  Data  Terminal  Ready  (from  system) 

The  fantall  port  has  a  Cinch  DB-25P  (male)  connector;  the  cable 
connector  to  modem  or  terminal  must  have  a  DB-25S  connector  or 
equivalent,  which  is  available  from  TRW,  AMP,  and  many  others. 

L.4.1.2  Current  Loop  Cable  Connector  (with  BBNCC  Model  5421) 

This  fantail  port  is  for  asynchronous  20ma  current  loop 
terminals.  Current  source  is  provided  by  the  system  for  all 
these  signals.  The  connectors  are  assembled  in  groups  of  3 
ports,  and  are  found  only  as  a  part  of  the  FPT  fantail.  All 

signals  are  straight  through  the  cable  without  crossing,  and  no 
jumpers  are  required  in  either  connector. 

pin  1  Spare 

2  Transimitter  Source  (from  system) 

3  Ground 

4  Receiver  Return  (to  terminal) 

5  Spare 

6  Spare 

7  Transmitter  Return  (to  system) 

3  Receiver  Source  (from  terminal) 

9  Spare 

The  fantail  port  has  a  Cinch  DE-9S  (female)  connector,  cable  to 
terminal  must  have  a  DE-9P  (male)  or  equivalent,  which  is 
available  from  TRW,  AMP,  and  many  others. 
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L.4.1.3  EIA  Terminal  Connector  (with  BBNCC  Model  5422) 

This  fantail  port  is  designed  for  terminals  with  an  EIA 
RS-232  interface  to  the  system.  The  connectors  are  part  of  the 
FPT  fantail  assembly,  with  3  connectors  as  ports  for  the 
asnchronous  multiplexor.  There  are  no  crossed  signals  or  jumpers 
added  to  this  cable. 


pin  1  Ground 

2  Transmitted  Data  (by  terminal) 

3  Received  Data  (by  terminal) 

4  Request  To  Send 

5  Clear  To  Send 

6  Data  Set  Ready 

7  Signal  Ground 

8  Data  Carrier  Detect 

9  VDC 

10  -  VDC 


The  fantail  port  has  a  Cinch  DB-25P  (female)  connector;  cable  to 
terminal  must  have  a  DB-25S  (male)  or  equivalent,  which  is 
available  from  TRW,  AMP,  and  many  others. 


L.4.1.4  RE-232/CCITT  V.28  Cable  Connector  (with  BBNCC  Model 
5432) 


This  connector  is  very  sirailiar  to  the  RS-232  terminal  and 
modem  cable  connector,  except  that  it  includes  the  CTS  signal, 
and  it  is  used  only  as  a  part  of  the  FPI  fantail  assembly,  by 
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single  units  instead  of  groups  of  8  ports.  Also^  this  port  will 
only  support  synchronous  modems ,  and  will  not  accept  terminals. 
All  signals  should  be  straight  through  the  cable,  with  no 
crossing  or  Jumpers  required. 

pin  1  Ground 

2  Transmitted  Data  (by  system) 

3  Received  Data  (by  system) 

4  Request  To  Send 

5  Clear  To  Send 

6  Data  Set  Ready 

7  Signal  Ground 

8  Data  Carrier  Detect 

9  ★  VDC 

10  -  VDC 

15  Transmitted  Clock 

17  Received  Clock 

20  Data  Terminal  Ready  (from  system) 

The  fantail  port  has  a  Cinch  DB*25P  (male)  connector;  cable  to 
modem  must  have  a  DB»25S  (female)  connector  or  e*quivalent,  which 
is  available  from  TRW,  AMP,  and  many  others. 

1.4. 1.5  Bell  303  Modem  Cable  Connector  (with  BBNCC  Model  5^31) 

This  port  is  designed  for  connections  to  the  Sell  303  modem. 
It  is  a  part  of  the  FPI  fantail  assembly  and  Is  provided  as  a 
single  port,  not  part  of  a  group. 
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pair  1  Send  Data 

1  Ground 

2  Loop  Test 

2  Ground 

3  Serial  Clock  Transmit 

3  Ground 

4  Read  Data 

4  Ground 

5  Serial  Clock  Receive 

5  Ground 


Bolt  Beranok  and  Newman  Inc 

pin  8 
27 
11 

30 
12 

31 
10 
29 
6 

25 


Cable  must  be  twisted  pair,  22  awg  or  larger.  The  suggested 
cable  is  Alpha  1323.  Fantail  port  has  a  Cinch  DC-37P  (male) 
connector;  cable  to  modem  must  have  DC-37S  (female)  connector  or 
equivalent,  which  is  available  from  TRW,  AMP,  and  many  others. 

L.4.1.6  Local  Host  Cable  Connection  (with  BBNCC  Model  5441) 

This  is  the  port  for  the  connection  of  a  Local  Host  to  a 
C/30  IMP  or  TIP.  For  further  information  about  this  connection, 
refer  to  the  body  of  this  report.  Connectors  are  part  of  the  FPT 


fantail  assembly. 

pair  1  Ready  for  next  IMP  bit  pin  1 

1  Ground  20 

2  There's  your  IMP  bit  2 

2  Ground  21 

3  Last  IMP  Bit  3 


12/81 


L-16 


3-514 


APPENDIX 


1822 


Report  No.  1822 


Ground 
IMP  Data 
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Ground 

Ready  for  Next  Host  Bit 
Ground 

There's  Your  Host  Bit 
Ground 

Last  Host  Bit 
Ground 
Host  Data 
Ground 

IMP  Master  Ready 
Ground 

IMP  Ready  Test 
Ground 

Host  Master  Ready 
Ground 

Host  Ready  Test 
Ground 


The  cable  for  this  connection  is  supplied  by  BBNCC,  and  is  the 
same  as  that  specified  in  Report  1822  for  the  Pluribus.  The 
fantail  port  has  a  Cinch  DC-37S  (female  connector;  the  cable  has 
a  Cinch  DC-37P  (male)  connector  at  the  C/30  end  and  has  a  frayed 
end  at  the  host  end. 
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L.4.1.7  Distant  Host  Cable  Connection  (with  BBNCC  Model  5442) 

This  is  the  port  for  the  connection  of  a  Distant  Host  to  a 
C/30  IMP  or  TIP.  For  further  information  about  this  connection, 
refer  to  the  body  of  this  report.  Connectors  are  part  of  the  FPT 


fantail  assembly. 

pair  1  Ready  For  Next  IMP  Bit  +  pin  1 

1  Ready  For  Next  IMP  Bit  -  20 

2  There’s  Your  IMP  Bit  +  15 

2  There's  Your  IMP  Bit  -  33 

3  Last  IMP  Bit  ♦  17 

3  Last  IMP  Bit  -  35 

4  IMP  Data  +  19 

4  IMP  Data  -  37 

5  Ready  For  Next  Host  Bit  ♦  13 

5  Ready  For  Next  Host  Bit  -  32 

6  There's  Your  Host  Bit  ♦  6 

6  There's  Your  Host  Bit  -  25 

7  Last  Host  Bit  ♦  7 

7  Last  Host  Bit  -  26 

3  Host  Data  ♦  8 

8  Host  Data  -  27 

9  IMP  Ready  Test  9 

9  IMP  Master  Ready  10 

10  Host  Master  Ready  11 

10  Host  Ready  Test  12 
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GND  Shield  Ground  22 

Cable  must  be  twisted  pair,  22  awg  or  larger.  Recommended  cables 
for  distances  less  than  300  feet  are  Columbia  6059  or  Belden  9768 
(22AWG,  12  pair;  U.L.  Listing  #2493).  For  distances  greater  than 
300  feet,  the  recommended  cables  are  SigNet  Type  Tel-U/SN  or 
Direct  Burial  Cable,  REA  Spec.  PE-23  (19AWG,  12  pair).  The 
fantail  port  has  a  Cinch  DC-37S  (female)  connector;  cable  to  IMP 
or  Host  must  have  a  DC-37P  (male)  connector.  These  connectors 
are  available  from  TRW,  AMP,  and  many  others.  If  the  cable  to 
the  IMP  or  Host  is  already  constucted  with  the  MIL  SPEC  connector 
specified  in  Report  1822  (MS24266R18B31PN) ,  a  DIDX  adaptor  cable 
may  be  ordered  from  BBN  Computer  to  connect  the  IMP  or  Host  cable 
to  the  fantail  port  connector  which  is  available  from  TRW,  AMP, 
and  many  others. 

L.4.2  Storage  Media 

The  only  storage  medium  needed  to  operate  the  C/30  is  a 
microcassette  supplied  by  BBN  Computer.  These  can  be  stored  in  a 
temperature  between  10  and  40  degrees  C  ^50-104  F)  with  a 
temperature  change  of  no  more  than  3*9  degrees  C  (7  F)  per  hour. 
Humidity  should  be  between  4%  and  30%  with  no  condensation.  Note 
that  the  rate  of  temperature  change  must  not  be  exceeded  in 
transfer  from  storage  to  use. 
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L.4.3  Computer  Room 


Aside  from  the  raised  floor  (if  used),  many  other  details 
must  be  considered  when  planning  a  computer  room.  Some  of  these 
concern  the  system  performance  and  reliability,  and  some  concern 
safety  precautions  for  the  system  and  the  operators.  Cosmetic 
details,  such  as  the  paint  colors  of  the  system,  should  also  be 
considered . 


L.4.3. 1  Air 


The  air  in  the  computer  room  should  not  only  be  maintained 
at  the  proper  temperature  and  humidity,  but  must  also  be  clean 
and  as  non-contaminated  as  possible.  That  is,  the  air  should  be 
filtered  by  the  air  conditioning  to  the  room,  and  if  possible, 
the  air  pressure  of  the  room  should  be  greater  than  that  of  the 
rooms  surrounding  it  such  that  an  open  door  will  not  allow  dust 
to  enter  the  room.  Smoking  should  be  prohibited  in  the  computer 
room.  The  same  precautions  should  be  taken  with  the  room  or  area 
where  the  system  media  are  stored.  Dust  of  any  sort  may  cause 
damage  to  the  storage  media,  which  may  also  damage  the  drive  if 
the  media  are  re-mounted. 


L.4.3. 2  Floor,  Ceiling,  and  Wall  Surfaces 


The  floor  of  the  computer  room,  whether  raised  or  not,  must 
be  as  static-free  as  possible.  This  is  best  done  with  tile, 
although  some  types  of  tile,  particularly  asbestos,  may  cause  as 
much  static  as  carpets.  In  addition,  the  floor,  ceiling,  and 


APPENDIX 


1822 


Report  No.  1822  Bolt  Beranek  and  Newman  Inc. 

walls  should  be  non-combustible  or  at  least  fire  retardant.  If 
possible,  the  walls  should  also  be  sound  absorbing,  to  reduce  the 
noise  level  in  the  computer  room  caused  by  the  system,  the  air 
conditioning,  and  the  operators. 

It  is  often  desirable  to  match  the  colors  of  the  computer 
room  to  the  colors  of  the  system.  BBN  Computer  cabinets  are 
provided  with  only  one  color  scheme.  The  sides  of  the  cabinets 
are  blue,  and  the  center  section  of  the  cabinets  are  off-white. 
The  blue  paint  is  colorchip  #25102  from  Federal  Standard  595. 
The  off-white  paint  is  colorchip  #27778,  also  from  Federal 
Standard  595. 

L.4.3.3  Fire  Precautions 

In  addition  to  fire  retardant  surfaces  on  the  floor, 
ceiling,  and  walls,  fire  extinguishers  should  be  installed,  and 
clearly  labelled,  in  the  computer  room.  Extinguishers  are 
necessary  for  both  the  electrical  systems  and  for  the  combustible 
paper  products  in  the  room.  Sprinkler  systems  may  also  be 
installed,  but  care  should  be  taken  in  planning  the  sprinklers 
such  that  their  use  will  not  damage  the  system,  the  storage 
media,  or  the  operators.  For  more  complete  information,  refer  to 
the  National  Fire  Protection  Association's  Standard  for  the 
Protection  of  Electronic  Coraputer/Data  Processing  Equipment,  NFPA 
No.  75. 
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This  RFC  specifies  the  ARPANET  182 2L  Host  Access  Protocol,  which 
Is  a  successor  to  the  existing  1822  Host  Access  Protocol.  1822L 
allows  APi^ANET  hosts  to  use  logical  names  as  well  as  1822 's 
physical  port  loca^'lons  to  address  each  other. 
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1  INTRODUCTION 

This  RFC  specifies  the  ARPANET  1822L  Host  Access  Protocol,  which 
will  allow  hosts  to  use  logical  addressing  (i.e.,  host  names  that 
are  independent  of  their  physical  location  on  the  ARPANET)  to 
communicate  with  each  other.  This  new  host  access  protocol  is 
known  as  the  ARPANET  1822L  (for  Logical)  Host  Access  Protocol, 
and  is  a  successor  to  the  current  ARPANET  1822  Host  Access 
Protocol,  which  is  described  in  sections  3.3  and  3.4  of  BBN 
Report  1822  [1].  Although  the  182 2L  protocol  uses  different 

Host- IMP  leaders  than  the  1822  protocol,  the  IMPs  will  continue 
to  support  the  1822  protocol,  and  hosts  using  either  protocol  can 
readily  communicate  with  each  other  (the  IMPs  will  handle  the 
translation  automatically)  . 

The  RFC’s  terminology  is  consistent  with  that  used  in  Report 
1822,  and  any  new  terms  will  be  defined  when  they  are  first  used. 
Familiarity  with  Report  1822  (section  3  in  particular)  is 
assumed.  As  could  be  e^qpected,  the  RFC  makes  many  references  to 
Report  1822.  As  a  result,  it  uses,  as  a  convenient  abbreviation, 
"see  1822 (x)"  instead  of  "please  refer  to  Report  1822,  section  x, 
for  further  details". 

This  RFC  v^xlates,  and  obsoletes,  RFC  851.  The  changes  from  that 
RFC  are: 


1  • 
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2  THE  ARPANET  1822L  HOST  ACCESS  PRCTTXOL 

The  ARPANET  1822L  Host  Access  Protocol  allows  a  host  to  use 
logical  addressing  to  coonunicate  with  other  hosts  on  the 
ARPANET.  Basically^  logical  addressing  allows  hosts  to  refer  to 
each  other  using  an  1822L  name  (see  section  2.1)  which  is 
independent  of  a  host's  physical  location  in  the  network.  lEN 
183  (also  published  as  BBN  Report  4473)  [2]  gives  the  use  of 
logical  addressing  considerable  justification.  Among  the 
advantages  it  cites  are: 

o  The  ability  to  refer  to  each  host  on  the  network  by  a  name 
independent  of  its  location  on  the  network. 

o  Allowing  different  hosts  to  share  the  same  host  port  on  a 
tims'division  basis. 

o  Allowing  a  host  to  use  multi -homing  (where  a  single  host  use&' 
more  than  one  port  to  communicate  with  the  network) . 

o  Allowing  several  hosts  that  provide  the  same  service  to  share 

the  same  name. 
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using  the  1822  or  the  1822L  protocol.  When  a  host  comes  up  on  an 
IMP,  it  declares  itself  to  be  an  1822  host  or  an  182 2L  host  by 
the  type  of  NOP  message  (see  section  3.1)  it  uses.  Once  up, 
hosts  can  switch  from  one  protocol  to  the  other  by  issuing  an 
appropriate  NOP.  Hosts  that  do  not  use  the  1822L  protocol  \/ill 
still  be  addressable  by  and  can  communicate  with  hosts  that  do, 
and  vice-versa. 

Another  difference  between  the  two  protocols  is  that  t}ie  1822 
leaders  are  symmetric,  while  the  1822L  leaders  are  not.  The  term 
symmetric  means  that  in  the  1822  protocol,  the  exact  same  leader 
format  is  used  for  messages  in  both  directions  between  the  hosts 
and  IMPS.  For  example,  a  leader  sent  from  a  host  over  a  cable 
that  was  looped  back  onto  Itself  (via  a  looping  plug  or  faulty 
hardware)  would  arrive  back  at  the  host  and  appear  to  be  a  legal 
message  from  a  real  host  (the  destination  host  of  the  original 
message) .  In  contrast,  the  1822L  headers  are  not  symmetric,  and 
a  host  can  detect  if  the  connection  to  its  IMP  is  looped  by 
receiving  a  message  with  the  wrong  leader  format.  This  allows 
the  host  to  take  appropriate  action  upon  detection  of  the  loop. 
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Hiis  format  allows  1822L  hosts  to  directly  address  hosts  0-63  at 
IMPS  1-255  (IMP  0  does  not  exist)  .  Note  that  the  highest  host 
numbers  are  reserved  for  addressing  the  IMP’S  internal  fake 
hosts.  At  this  writing,  the  IMP  has  seven  fake  hosts,  so  host 
numbers  57-63  address  the  IMP  fake  hosts,  while  host  numbers  0-56 
address  real  hosts  external  to  the  IMP.  As  the  number  of  IMP 
fake  hosts  changes,  this  boundary  point  will  also  change. 

2 . 2  Name  Translations 

There  are  a  number  of  factors  that  determine  how  an  182 2L  name  is 
translated  by  the  IMP  into  a  physical  address  on  the  network. 
These  factors  include  which  translation.?  are  legal;  in  vhat  order 
different  translations  for  the  same  name  should  be  attempted; 
which  legal  translations  shouldn’t  be  attempted  because  a 
particular  host  port  is  down;  and  the  interoperability  between 
1822  and  1822L  hosts.  These  issues  are  discussed  in  the 
following  sections. 

2.2.1  Authorization  and  Effectiveness 

Every  host  on  a  C/30  IMP,  regardless  of  whether  it  is  using  the 
1822  or  1822L  protocol  to  access  the  network,  can  have  one  or 
more  1822L  names  (logical  addresses) .  Hosts  using  1822L  can  then 
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use  these  names  to  address  the  hosts  in  the  network  Independent 
of  their  physical  locations.  Because  of  the  implementation 
constraints  mentioned  in  the  introduction,  hosts  on  non-C/30  IMPs 
cannot  be  assigned  182 2L  names.  To  circumvent  this  restriction, 
however,  1822L  hosts  can  also  use  1822L  addresses  to  access  all 
of  the  other  hosts. 

At  this  point,  several  questions  arise:  How  are  these  names 
assigned,  how  do  they  become  known  to  the  IMPs  (so  that 
translations  to  physical  addresses  can  be  made) ,  and  how  do  the 
IMPS  know  which  host  is  currently  using  a  shared  port?  To  answer 
each  question  in  order: 

Names  are  assigned  by  a  central  network  administrator.  When  each 
name  is  created,  it  is  assigned  to  a  host  (or  a  group  of  hosts) 
at  one  or  more  specific  host  ports.  The  host(s)  are  allowed  to 
reside  at  those  specific  host  ports,  and  nowhere  else.  If  a  host 
moves,  it  will  keep  the  same  name,  but  the  administrator  has  to 
update  the  central  database  to  reflect  the  new  host  port. 
Changes  to  this  database  are  distributed  to  the  IMPs  by  the 
Network  Operations  Center  (NOC)  .  For  a  while,  the  host  may  be 
allowed  to  reside  at  either  of  (or  both)  the  new  and  old  ports. 
Once  the  correspondence  between  a  name  and  one  or  more  hosts 
ports  where  it  may  be  used  has  been  made  official  by  the 
administrator,  that  name  is  said  to  be  authorized  1822L 
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addresses,  which  actually  refer  to  physical  host  ports,  are 
always  authorized  in  this  sense. 

Once  a  host  has  been  assigned  one  or  more  names,  it  has  to  let 
the  IMPS  know  where  it  is  and  \^at  name(s)  it  is  using.  There 
are  two  cases  to  consider,  one  for  1822L  hosts  and  another  for 
1822  hosts.  The  following  discussion  only  pertains  to  hosts  on 
C/30  IMPS. 

When  an  IMP  sees  an  182 2L  host  come  »jp  on  a  host  port,  the  IMP 
has  no  way  of  knowing  which  host  has  Just  come  uqp  (several  hosts 
may  share  the  same  port,  or  one  host  may  prefer  to  be  known  by 
different  names  at  different  times)  .  This  requires  the  host  to 
declare  itself  to  the  IMP  before  it  can  actually  -send  and  receive 
messages.  This  function  is  performed  by  a  new  host-to-IMP 
message,  the  Name  Declaration  Message  (NDM) ,  which  lists  the 
names  that  the  host  would  like  to  be  known  by.  The  IMP  checks 
its  tables  to  see  if  each  of  the  names  is  authorized,  and  sends 
an  NDM  Reply  to  the  host  saying  which  names  were  actually 
authorized  and  can  now  be  used  for  sending  and  receiving  messages 
(i.e.,  which  names  are  effective)  .  A  host  can  also  use  an  NDM 
message  to  change  its  list  of  effective  names  (it  can  add  to  and 
delete  from  the  list)  at  any  time.  The  only  constraint  on  the 
host  is  that  any  names  it  wishes  to  use  can  become  effective  only 
if  they  are  authorized. 
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In  the  second  case^  if  a  host  comes  up  on  a  C/30  IMP  using  the 
1822  protocol,  the  IMP  automatically  makes  the  first  name  the  IMP 
finds  in  its  tables  for  that  host  become  effective  when  it 
receives  the  first  1822  NOP  from  the  host.  Thus,  even  though  the 
host  is  using  the  1822  protocol,  it  can  still  receive  messages 
from  1822L  hosts  via  its  1822L  name.  Of  course,  it  can  also 
r€»ceive  messages  from  an  182 2L  host  via  its  182 2L  address  as 
well.  (Remember,  the  distinction  between  1822L  names  and 
addresses  is  that  the  addresses  correspond  to  physical  locations 
on  the  network,  while  the  names  are  strictly  logical 
identifiers) .  The  IMPs  translate  between  the  different  leaders 
and  send  the  proper  leader  in  each  case  (see  section  2.2.4)  . 

The  third  question  above  has  by  now  already  been  answered.  When 
an  182 2L  host  comes  up,  it  uses  the  NDM  message  to  tell  the  IMP 
which  host  it  is  (which  names  it  is  known  by)  .  Even  if  this  is  a 
shared  port,  the  IMP  knows  which  host  is  currently  connected. 

Whenever  a  host  goes  down,  its  names  automatically  become  non- 
effective.  When  it  comes  back  up,  it  has  to  make  them  effective 
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Several  hosts  can  share  the  same  1822L  name.  If  more  than  one  of 
these  hosts  is  \jp  at  the  same  time,  any  messages  sent  to  that 
182 2L  name  will  be  delivered  to  just  one  of  the  hosts  sharing 
that  name,  and  a  RFNM  will  be  returned  as  usual.  However,  the 
sending  host  will  not  receive  any  indication  of  which  host 
received  the  message,  and  sxibsequent  messages  to  that  name  are 
not  guaranteed  to  be  sent  to  the  same  host.  Typically,  hosts 
providing  exactly  the  same  service  could  share  the  same  1822L 
name  in  this  manner. 


similarly,  when  a  host  is  multi'homed,  the  same  1822L  name  may 
refer  to  more  than  one  host  port  (all  connected  to  the  same 
host)  ,  If  the  host  is  up  on  only  one  of  those  ports,  that  port 
will  be  used  for  all  messages  addressed  to  the  host.  However,  if 
the  host  were  up  on  more  than  one  port,  the  message  would  be 
delivered  over  just  one  of  those  ports,  and  the  subnet  would 
choose  which  port  to  use.  This  port  selection  could  change  from 
message  to  message.  If  a  host  wanted  to  insure  that  certain 
messages  were  delivered  to  it  on  specific  ports,  these  messages 
could  use  either  the  port's  1822L  address  or  a  specific  1822L 
name  that  referred  to  that  port  alone. 
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Ihree  different  address  selection  policies  are  available  for  the 
name  maj^ing  process.  When  translated,  each  name  uses  one  of  the 
three  policies  (the  policy  is  pre-determined  on  a  per-name 
basis) .  The  three  policies  are: 

o  Attempt  each  translation  in  the  order  in  which  the  physical 
addresses  are  listed  in  the  IMF’s  translation  tables,  to  find 
the  first  reachable  physical  host  address.  This  list  is 
always  searched  from  the  top  whenever  an  uncontrolled  packet 
is  to  be  sent  or  a  new  virtual  circuit  connection  has  to  be 
created  (see  section  2.5).  This  is  the  most  commonly  used 
policy. 

o  Selection  of  the  closest  physical  address,  which  uses  the 
imp’s  routing  tables  to  find  the  translation  to  the 
destination  IMP  with  the  least  delay  path  whenever  an 
uncontrolled  packet  is  to  be  sent  or  a  new  virtual  circuit 
connection  has  to  be  created. 


o  Use  load  leveling.  This  is  similar  to  the  second  policy,  but 
differs  in  that  searching  the  address  list  for  a  valid 
translation  starts  at  the  address  following  where  the  previous 
translation  search  ended  whenever  an  uncontrolled  packet  is  to 
be  sent  or. a  new  virtual  circuit  connection  has  to  be  created. 
This  attempts  to  spread  out  the  load  from  any  one  IMP's  hosts 
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host,  and  the  name  maps  to  only  one  authorized  host  port, 
then  a  type  7  message  will  also  be  sent  to  the  source  host. 

A3.  If  an  1822L  name  is  being  used  to  specify  the  destination 
host,  and  the  name  maps  to  more  than  one  authorized  host 
port,  then  the  IMP  attempts  to  open  a  connection  to  another 
authorized  and  effective  host  port  for  that  name.  If  no 
such  connection  can  be  made,  the  host  will  receive  a  type  15 
(1822L  Name  or  Address  Error) ,  subtype  5  (no  effective 
translations)  message  (see  section  3.2) .  Note  that  a  type  7 
message  cannot  be  returned  to  ^e  source  host,  since  type  7 
messages  refer  to  a  particular  destination  host  port,  and 
the  name  maps  to  more  than  one  destination  p>ort. 

Things  get  a  bit  more  complicated  if  there  are  any  outstanding 
messages  on  the  connection  when  the  destination  host  goes  down. 

The  connection  will  be  closed,  and  one  of  the  following  will 
occur: 

Bl.  If  1822  or  an  1822L  address  is  being  used  to  specify  the 
destination  host,  then  the  source  host  will  receive  a  pfpe  7 
message  for  each  outstanding  message. 

B2.  If  an  1822L  name  is  being  used  to  specify  the  destination 

host,  then  the  source  host  will  receive  a  type  9  (Inconplete  | 
Transmission) .  subtyp>e  6  (message  lost  due  to  logically  1 
addressed  host  going  down)  message  for  each  outstanding  | 
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message.  The  next  time  the  source  host  submits  another 
message  for  that  same  destination  name,  the  previous 
algorithm  will  be  used  (either  step  A2  or  step  A3)  . 

The  above  two  algorithms  also  apply  when  a  host  stays  up,  but 
declares  the  destination  name  for  an  existing  connection  to  no 
longer  be  effective.  In  this  case,  however,  the  type  7  messages 
above  will  be  replaced  by  type  15,  subtype  3  (name  not  effective) 
messages . 

Section  2.3  discusses  how  destination  host  downs  are  handled  for 
uncontrolled  packets. 

2.2.4  1822L  and  1822  Interoperability 

As  has  been  previously  stated,  1822  and  1822L  hosts  can 
IntercosBDunlcate,  and  the  IMPs  will  automatically  handle  any 
necessary  leader  and  address  format  conversions.  However,  not 
every  combination  of  1822  and  1822L  hosts  allows  full 
Interoperability  with  regard  to  the  use  of  1822L  names,  since 
1822  hosts  are  restricted  to  using  physical  addresses. 

There  are  two  possible  situations  where  any  Incompatibility  could  | 
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o  An  1822  host  sending  a  mesvage  to  1822L  host:  The  1822 

host  specifies  the  dcistination  host  by  its  1822  address.  The 
destination  host  will  receive  the  message  with  an  1822L  leader 
containing  the  1822L  addresses  of  the  source  and  destination 
hosts. 

o  An  1822L  host  sending  a  message  to  an  1822  host:  The  1822L 

host  can  use  1822L  names  or  addresses  to  spcscify  both  the 
source  and  destination  hosts.  The  destination  host  will 
receive  the  message  with  an  1822  leader  containing  the  1822 
address  of  the  source  host. 


2.3  Uncontrolled  Packets 

Uncontrolled  packets  (see  1822(3.6))  present  a  unique  problem  for 
the  182 2L  protocol.  Uncontrolled  packets  use  none  of  the  normal 
ordering  and  error-control  mechanisms  in  the  IMP,  and  do  not  use 
the  normal  virtual  circuit  connection  facilities.  As  a  result, 
uncontrolled  packets  need  to  carry  all  of  their  overhead  with 
them,  including  source  and  destination  names.  If  1822L  names  are 
used  when  sending  an  uncontrolled  packet,  additional  information 
is  now  required  by  the  subnetwork  when  the  packet  is  transferred 
to  ihe  destination  IMP.  This  means  that  less  host-to-host  data 
can  be  contained  in  the  packet  than  is  possible  between  1822 


16  - 


1985 


3-S40 


APPENDIX 


RFC  878 


1822L  Host  Access  Protocol  Decesober  1983 

RFC  878 

bests. 

f 

Uncontrolled  packets  that  are  sent  between  1822  hosts  may  contain 
not  more  than  991  bits  of  data.  Uncontrolled  packets  that  are 
sent  to  and/or  from  1822L  hosts  are  limited  to  32  bits  less,  or 
not  more  than  959  bits.  Packets  that  exceed  this  length  will 
result  in  an  error  indication  to  the  host,  and  the  packet  will 
not  be  sent.  Ihis  error  indication  represents  an  enhancement  to 
the  previous  level  of  service  provided  by  the  IMP,  which  would 
sinply  discard  an  overly  long  uncontrolled  packet  without 
notification. 

Other  enhancements  that  are  provided  for  uncontrolled  packet 
service  are  a  notification  to  the  host  of  any  errors  that  are 
detected  by  the  host's  IMP  when  it  receives  the  packet.  A  host 
will  be  notified  if  an  uncontrolled  packet  contains  an  error  in 
the  1822L  name  specification,  such  as  if  the  name  is  not 
authorized  or  effective,  if  the  remote  host  is  unreachable  (%#hich 
is  indicated  by  none  of  its  names  being  effective),  if  network 
congestion  control  throttled  the  packet  before  it  left  the  source 
IMP,  or  for  any  other  reason  the  source  IMP  was  not  able  to  send 
the  packet  on  its  way. 

In  most  cases,  the  host  will  not  be  notified  if  the  uncontrolled 
packet  was  lost  once  it  was  transmitted  by  the  source  IMP. 
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However,  the  IMP  will  attenpt  to  notify  the  source  host  if  a 
logically- addressed  uncontrolled  packet  was  mistakenly  sent  to  a 
host  that  the  source  IMP  thou^t  was  effective,  but  which  turned 
out  to  be  dead  or  non-effective  at  the  destination  IMP.  This 
non-delivery  notice  is  sent  back  to  the  source  IMP  as  an 
uncontrolled  packet  from  the  destination  IMP,  so  the  source  host 
is  not  guaranteed  to  receive  this  indication. 

If  the  source  IMP  successfully  receives  the  non-delivery  notice, 
then  the  source  host  will  receive  a  type  15  (1822L  Name  or 
Address  Error),  subtype  6  (down  or  non-effective  port)  message. 
If  the  packet  is  resubmitted  or  another  packet  is  sent  to  the 
same  destination  name,  and  there  are  no  available  effective 
translations,  then  the  source  host  will  receive  a  type  15, 
subtyp>e  5  (no  effective  translations)  message  if  the  destination 
name  has  more  than  one  mapping;  or  will  receive  either  a  type  7 
(Destination  Host  Dead)  or  a  type  15,  subtype  3  (name  not 
effective)  message  if  the  destination  name  has  a  single 
translation. 

Those  enhancements  to  the  uncontrolled  packet  service  that  are 
not  specific  to  logical  addressing  will  be  available  to  hosts 
using  1822  as  well  as  1822L.  However,  uncontrollea  packets  must 
be  sent  using  1822L  leaders  in  order  to  receive  any  indication 
that  the  packet  was  lost  once  it  has  left  the  source  IMP. 
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2.4  Establishing  Host- IMP  Communications 

When  a  host  comes  vjp  on  an  IMP,  or  after  there  has  been  a  break 
in  the  communications  between  the  host  and  its  IMP  (see 
1822(3.2)),  the  orderly  flow  of  messages  between  the  host  and  the 
IMP  needs  to  be  properly  (re)  established.  This  allows  the  IMP 
and  host  to  recover  from  most  any  failure  in  the  other  or  in 
their  communications  path,  including  a  break  in  mid-message. 

The  first  messages  that  a  host  should  send  to  its  IMP  are  three 
NOP  messages.  Three  messages  are  required  to  insure  that  at 
least  one  message  will  be  properly  read  by  the  IMP  (the  first  NOP 
could  be  concatenated  to  a  previous  message  if  communications  had 
been  broken  in  mid-stream,  and  the  third  provides  redundancy  for 
the  second) .  These  NOPs  serve  several  functions:  they 
synchronize  ^e  I^®>  with  the  host,  they  tell  the  IMP  how  much 
padding  the  host  requires  between  the  message  leader  and  its 
body,  and  they  also  tell  the  IMP  whether  the  host  will  be  using 
1822  or  1822L  leaders. 

Similarly,  the  IMP  will  send  three  NOPs  to  the  host  when  it 
detects  that  the  host  has  come  up.  Actually,  the  IMP  will  send 
six  NOPs,  alternating  three  1022  NOPs  with  three  1022L  NOPs. 
Thus,  the  host  will  see  three  NOPs  no  matter  which  protocol  it  is 
using.  The  NOPs  will  be  followed  by  two  Interface  Reset 
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messages,  one  of  each  style.  If  the  IMP  receives  a  NOP  from  the 
host  while  the  above  sequence  is  occurring,  the  IMP  will  only 
send  the  remainder  of  the  NOPs  and  the  Interface  Reset  in  the 
proper  style.  The  1822  NOPs  will  contain  the  1822  address  of  the 
host  interface,  and  the  1822L  NOPs  will  contain  the  corresponding 
1822L  address. 

Once  the  IMP  and  the  host  have  sent  each  other  the  above 
messages,  regular  communications  can  commence.  See  1822(3.2)  for 
further  details  concerning  the  ready  line,  host  tardiness,  and 
other  issues. 

j 

2.5  Counting  RFNMs  When  Using  1822L 

When  a  host  submits  a  regular  message  using  an  1822  leader,  the 
IMP  checks  for  an  existing  simplex  virtual  circuit  connection 
(see  1822(3.1))  from  the  source  host  to  the  destination  host.  If 
such  a  connection  already  exists,  it  is  used.  Otherwise,  a  new 
connection  from  the  source  host  port  to  the  destination  host  port 
is  opened.  In  either  case,  there  may  be  at  most  eight  messages 
outstanding  on  that  connection  at  any  one  time.  If  a  host 
submits  a  ninth  message  on  that  connection  before  it  receives  a 
reply  for  the  first  message,  then  the  host  will  be  blocked  until 
the  reply  is  sent  for  the  first  message. 
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Such  connections  can  stay  open  for  some  time,  but  are  timed  out 
after  three  minutes  of  no  activity,  or  can  be  closed  if  there  is 
contention  for  the  connection  blocks  in  either  the  source  or 
destination  IMP.  However,  a  connection  will  never  be  closed  as 
long  as  there  are  any  outstanding  messages  on  it.  This  allows  a 
source  host  to  count  the  nun&er  of  replies  it  has  received  for 
messages  to  each  destination  host  address  In  order  to  avoid  being 
blocked  by  submitting  a  ninth  outstanding  message  on  any 
connection . 

When  a  host  submits  a  regular  message  using  an  1822L  leader,  a 
similar  process  occurs,  except  that  in  this  case,  connections  are 
distinguished  by  the  source  port/source  name/destination  name 
coxnbination .  When  the  message  is  received  from  a  host,  the  IMP 
first  looks  for  an  open  connection  for  that  same  port  and  source 
name/destination  name  pair.  If  such  a  connection  Is  found,  then 
It  Is  used,  and  no  further  name  translation  is  performed.  If, 
however,  no  open  connection  was  found,  then  the  destination  name 
is  translated,  and  a  connection  opened  to  the  physical  host  port. 
As  long  as  there  are  any  outstanding  messages  on  the  connection 
it  will  stay  open,  and  it  will  have  the  same  restriction  that 
only  eight  messages  may  be  outstanding  at  any  one  time.  Thus,  a 
source  host  can  still  count  replies  to  avoid  being  blocked,  but 
they  must  be  counted  on  a  source  port  and  source  name/destination 
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name  pair  basis,  instead  of  just  by  source  port  and  destination 
host  address  as  before. 

Since  connections  are  based  on  the  source  name  as  well  as  the 
destination  name,  this  implies  that  there  may  be  more  than  one 
open  connection  from  physical  host  port  A  to  physical  host  port 
B,  which  would  allow  more  than  8  outstanding  messages 
simultaneously  from  the  first  to  the  second  port.  However,  for 
this  to  occur,  either  the  source  or  destination  names,  or  both, 
must  differ  from  one  connection  to  the  next.  For  example,  if  the 
names  "543"  and  "677"  both  translate  to  physical  port  3  on  IMP 
51,  then  the  host  on  that  port  could  open  four  connections  to 
itself  by  sending  messages  from  "543"  to  "543",  from  "543"  to 
"677",  from  "677"  to  "543",  and  from  "677"  to  "677". 

As  has  already  been  stated,  the  destination  names  in  regular 
messages  are  only  translated  when  conn^tions  are  first  opened. 
Once  a  connection  is  open,  that  connection,  and  its  destination 
physical  host  port,  will  continue  to  be  used  until  it  is  closed. 
If,  in  the  meantime,  a  "better"  destination  host  port  belonging 
to  the  same  destination  name  became  available,  it  would  not  be 
used  until  the  next  time  a  new  connection  is  opened  to  tliat 


destination  name. 
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Also,  the  act  of  making  an  182 2L  name  be  non-effective  will  not 
automatically  cause  any  connections  using  that  name  to  be  closed. 
However,  they  will  be  closed  after  at  most  three  minutes  of 
inactivity.  A  host  can,  if  it  wishes,  make  all  of  its  names  at  a 
port  be  noneffective  and  close  all  of  its  connections  to  and  from 
the  port  by  flapping  the  host's  ready  line  to  that  IMP  port. 


2.6  1822L  Name  Server 

There  may  be  times  when  a  host  wants  to  perform  its  own 
translations,  or  might  need  the  full  list  of  physical  addresses 
to  which  a  particular  name  maps.  For  exaaple,  a  connection -based 
host-to-host  protocol  may  require  that  the  same  physical  host 
port  on  a  multi -homed  host  be  used  for  all  messages  using  that 
host-to-host  connection,  and  the  host  does  not  wish  to  tnast  the 
IMP  to  always  deliver  messages  using  a  destination  name  to  the 
same  host  port. 

In  these  cases,  the  host  can  submit  a  type  11  (Name  Server 
Request)  message  to  the  IMP,  which  requests  the  IMP  to  translate 
the  destination  1822L  name  and  return  a  list  of  the  addresses  to 
which  it  maps.  The  IMP  will  respond  with  a  type  11  (Name  Server 
Reply)  message,  which  contains  the  selection  policy  in  use  for 
that  name,  the  number  of  addresses  to  which  the  name  maps,  the 
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k  addresses  themselves,  and  for  each  address,  whether  it  is 

I 

effective  and  its  routing  distance  from  the  IMP.  See  section  3.2 
for  a  complete  description  of  the  message's  contents. 

1 

Using  this  information,  the  source  host  could  make  an  informed 
decision  on  which  of  the  physical  host  ports  corresponding  to  an 
1822L  name  to  use  and  then  send  the  messages  to  that  port,  rather 
than  to  the  name. 

The  IMP  also  supports  a  different  type  of  name  service.  A  host 
needs  to  issue  a  Name  Declaration  Message  to  the  IMP  in  order  to 
make  its  names  effective,  but  it  may  not  wish  to  keep  its  names 
in  some  table  or  file  in  the  host.  In  this  case,  it  can  ask  the 
IMP  to  tell  it  which  names  it  is  authorized  to  use. 

In  this  case,  the  host  submits  a  type  12  (Port  List  Request) 
message  to  the  IMP,  and  the  IMP  replies  with  a  type  12  (Port  List 
Reply)  message.  It  contains,  for  the  host  port  over  which  the 
IMP  received  the  request  and  sent  the  reply,  the  number  of  names 
that  map  to  the  port,  the  list  of  names,  and  whether  or  not  each 
name  is  effective.  The  host  can  then  v^se  this  information  in 
order  to  issue  the  Name  Declaration  Message.  Section  3.2 
contains  a  complete  description  of  the  reply's  contents. 


AFFl!;iNDlX 


iVX’  O  I  o 


1822L  Host  Access  Protocol  December  1983 

RFC  878 

3  182 2L  LEADER  FORMATS 

The  following  sections  describe  the  formats  of  the  leaders  that 
precede  messages  between  an  182 2L  host  and  its  IMP.  They  were 
designed  to  be  as  compatible  with  the  1822  leaders  as  possible. 
The  second,  fifth,  and  sixth  words  are  identical  in  the  two 
leaders,  and  all  of  the  existing  functionality  of  the  1822 
leaders  has  been  retained.  In  the  first  word,  the  1822  New 
Format  Flag  is  now  also  used  to  identify  the  two  types  of  182 2L 
leaders,  and  the  Handling  Type  has  been  moved  to  the  second  byte. 
The  third  and  fourth  words  contain  the  Source  and  Destination 
1822L  Name,  respectively. 
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3.1  Host-to-IMP  1822L  Leader  Format 


1  4  5  8  9 


I  I  1822L  I  I 

I  Unused  |  H2I  |  Handling  Type  | 

I  I  flag  I  I 

^ - 4 - + - + 

17  20  21  22  24  25  32 

+ - +-+ - + - + 

I  |T|Leader|  | 

I  Unused  jR| Flags  j  Message  Type  | 

I  |C|  I  I 

.J. - - 4 - 4 

33  48 


Source  Host 


Destination  Host 


76  77  80 


Message  ID 


i  Sub- type j 


Unused 


Host-to-IMP  1822L  Leader  Format 
Figure  3.1 
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Bits  1-4:  Unused,  must  be  set  to  zero. 

Bits  5-8:  1822L  Host- to- IMP  Flag: 

This  field  is  set  to  decimal  13  (1101  in  binary) . 

Bits  9-16:  Handling  Typo: 

This  field  is  bit-coded  to  indicate  the  transmission 
characteristics  of  the  connection  desired  by  the  host.  See 
1822(3.3)  . 

Bit  9:  Priority  Bit: 

Mesf  ages  with  this  bit  on  will  be  treated  as  priority 
messages . 

Bits  10-16:  Unused,  must  be  zero. 

Bits  17-20:  Unused,  must  be  zero. 

Bit  21:  Trace  Bit: 

If  equal  to  one,  this  message  is  designated  for  tracing  as 
it  proceeds  through  the  network.  See  1822(5.5) . 

Bits  22-24:  Leader  Flags; 

Bit  22:  A  flag  available  for  use  by  the  destination  host. 
See  1822(3.3)  for  a  description  of  its  use  by  the  IMP's 
TTY  Fake  Host. 

Bits  23-24:  Reserved  for  future  use,  must  be  zero. 
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Bits  25-32:  Message  Type: 

Type  0:  Regular  Message  -  All  host-to-host  communication 
occurs  via  regular  messages,  which  have  several  sub- 
types,  found  in  bits  77-80.  These  sub- types  are: 

0:  Standard  -  The  IMP  uses  its  full  message  and  error 
control  facilities,  and  host  blocking  may  occur. 

3:  Uncontrolled  Packet  -  The  IMP  will  perform  no 
message -control  functions  for  this  type  of 
message,  and  network  flow  and  congestion  control 
may  cause  loss  of  the  packet.  Also  see  1822(3.6) 
and  section  2.3. 

1-2,4-15:  Unassigned. 

Type  1:  Error  Without  Message  ID  -  See  1822(3.3) . 

Type  2:  Host  Going  Down  -  see  1822(3.3) . 

Type  3:  Name  Declaration  Message  (NDM)  -  This  message  is 
used  by  the  host  to  declare  which  of  its  1822L  names  is 
or  is  not  effective  (see  section  2.2.1),  or  to  make  all 
of  its  names  non-effective.  The  first  16  bits  of  the 
data  portion  of  the  NDM  message,  following  the  leader 
and  any  leader  padding,  contains  the  number  of  1822L 
names  contained  in  the  message.  This  is  followed  by 
the  1822L  name  entries,  each  32  bits  long,  of  which  the 
first  16  bits  is  a  1822L  name  and  the  second  16  bits 
contains  either  of  the  Integers  zero  or  one.  Zero 
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indicates  that  the  name  should  not  be  effective,  and 
one  indicates  that  the  name  should  be  effective.  The 
IMP  will  reply  with  a  NDM  Reply  message  (see  section 
3.2)  indicating  v?hich  of  the  names  are  now  effective 
and  which  are  not.  Pictorial ly,  a  NDM  message  has  the 
following  format  (including  the  loader,  which  is 
printed  in  hexadecimal ,  and  without  any  leader 
padding) ; 
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1822(3.3)  still  hold.  The  host  should  always  Issue 
NOPs  in  groups  of  three  to  instire  proper  reception  by 
the  IMP.  Also  see  section  2.4  for  a  further  discussion 
on  the  use  of  the  NOP  message. 

Type  8:  Error  with  Message  ID  -  see  1822(3.3)  . 

Type  11:  Name  Server  Request  '  This  allows  the  host  to  use 
the  imp's  logical  addressing  tables  as  a  name  server. 
The  de9::lnatlon  ndmi  In  the  1822L  leader  Is  translated, 
and  the  IMP  replies  with  a  Name  Server  Reply  message, 
which  lists  the  physical  host  addresses  to  which  the 
destination  name  maps. 

Type  12:  Port  List  Request  -  This  allows  the  physical  host 
to  request  the  list  of  names  that  m^  to  the  host  port 
over  which  this  request  was  received  by  the  IMP.  The 
IMP  replies  with  a  Port  List  Reply  message,  which  lists 
the  names  that  map  to  the  port. 

Types  5-7,9-10,13-255:  Unasslgned. 

Bits  33-48:  Source  Host: 

This  field  contains  one  of  the  source  host's  1822L  names 
(or,  alternatively,  the  1822L  address  of  the  host  port  the 
message  Is  being  sent  over)  .  This  field  Is  not 
automatically  filled  In  by  the  IMP,  as  In  the  1822  protocol, 
because  the  host  may  be  known  by  several  names  and  may  wish 
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to  use  a  particular  name  as  the  source  of  this  message.  All 
messages  from  the  same  host  need  not  use  the  same  name  in 
this  field.  Each  source  name,  when  used,  is  checked  for 
authorization,  effectiveness,  and  actually  belonging  to  this 
host.  Messages  using  names  that  do  not  satisfy  all  of  these 
requirements  will  not  be  delivered,  and  will  instead  result 
in  an  error  message  being  sent  back  into  the  source  host. 
If  the  host  places  its  1822L  address  in  this  field,  the 
address  is  checked  to  insure  that  it  actually  represents  the 
host  port  where  the  message  originated. 

Bits  49-64:  Destination  Host; 

This  field  contains  the  182 2L  name  or  address  of  tlie 
destination  host.  If  it  contains  a  name,  the  name  will  be 
checked  for  effectiveness,  with  an  error  message  returned  to 
the  source  host  if  the  name  is  not  effective. 

Bits  65-76;  Message  ID; 

This  is  a  host- specified  identification  used  in  all  type  0 
and  type  8  messages,  and  is  also  used  in  type  2  messages. 
When  used  in  type  0  messages,  bits  65-72  are  also  known  as 
the  Link  Field,  and  should  contain  values  specified  in 
Assigned  Numbers  [3]  appropriate  for  the  host-to-host 
protocol  being  used. 
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3.2  IMP-to-Host  1822L  Leader  Format 


- 


1  4  5  8  9  16 

+ - + - + - + 

I  I  1822L  I  I 

I  Unused  |  I2H  |  Handling  Type  | 

I  I  Flag  I  I 

+ - + - + - + 

17  20  21  22  24  25  32 

+ - +-+ - + - + 

I  |T|Leader|  | 

I  Unused  jR| Flags  j  Message  Type  j 

I  |C|  !  ! 

-► - +--► - + - + 
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I  I 

+ - + 

49  64 

+ - + 

I  I 

I  Destination  Host  { 
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- 

65  76  77  80 

- + - ^ 

I  I  I 

I  Message  ID  |Sub-type| 

I  I  I 

+ - ^ - + 

81  96 

^ - + 

I  I 

I  Message  Length  | 

I  I 

+ - - + 


IMP-to-Host  1822L  Leader  Format 
Figure  3.3 
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Bits  1-4:  Unused  and  set  to  zero. 

Bits  5-8;  1822L  IMP-to-Host  Flag; 

This  field  is  set  to  decimal  14  (1110  in  binary) . 

Bits  9-16:  Handling  Type^ 

This  has  the  value  assigned  by  the  source  host  (see  section 
3.1)  .  This  field  is  only  used  in  message  types  0,  5-9,  and 
15. 


Bits  17-20;  Unused  and  set  to  zero. 

Bit  21;  Trace  Bit: 

If  equal  to  one,  the  source  host  designated  this  message  for 

tracing  as  it  proceeds  throu^  the  network.  See  1822(5.5)  . 

Bits  22-24:  Leader  Flags: 

Bit  22:  Available  as  a  destination  host  flag. 

Bits  23-24:  Reserved  for  future  use,  set  to  zero. 

Bits  25-32:  Message  Typ«: 

Typo  0:  Regular  Message  -  All  host-to-host  communication 
occurs  via  regular  messages,  which  have  several  sub- 
types.  The  sub-type  field  (bits  77-80)  is  the  same  as 
sent  in  the  host-to-IMP  leader  (see  section  3.1) . 


Type  1:  Error  in  Leader  -  See  1822(3.4) .  In  addition  to  its  | 
already  defined  sub- types,  tiiis  message  has  two  new  | 
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sub-types : 

4:  Illegal  Leader  Style  -  The  host  submitted  a  leader 
in  which  bits  5-8  did  not  contain  the  value  13, 
14,  or  15  decimal. 

5:  Wrong  Leader  Style  -  The  host  submitted  an  182 2L 
leader  when  the  IMP  was  e5g>ecting  an  1822  leader, 
or  vice-versa. 

Type  2:  IMP  Going  Down  -  See  1822(3.4) . 

Type  3:  NDM  Reply  -  This  is  a  reply  to  the  NDM  host-to-IMP 
message  (see  section  3.1)  .  It  will  have  the  same 
number  of  entries  as  the  NDM  message  that  is  being 
replying  to,  and  each  listed'  182  2L  name  will  be 
accompanied  by  a  zero  or  a  one  (see  figure  3.2)  .  A 

zero  signifies  that  the  name  is  not  effective,  and  a 
one  means  that  the  name  is  now  effective. 

Type  4:  NOP  -  The  host  should  discard  this  message.  It  is 
used  during  initialization  of  the  IMP /host 

communication.  The  Destination  Host  field  will  contain 
the  1822L  Address  of  the  host  port  over  which  the  NOP 
is  being  sent.  All  other  fields  are  unused. 

Type  5:  Ready  for  Next  Mesi^ags  -  See  1822(3.4). 

Type  6:  Dead  Host  Status  -  See  1822(3.4) . 

Type  7:  Destination  Host  or  IMP  Dead  (or  unknown)  -  See 

A\ 


APPENDIX 


RFC  878 


182 2L  Host  Access  Protocol 
RFC  878 


December  1983 


Type  8:  Error  in  Data  -  See  1822(3.4) . 

Type  9:  Incomplete  Transmission  -  See  1822(3.4).  In 
addition  to  its  already  defined  sub- types,  this  message 
has  one  new  sub- type: 

6:  Logically  Addressed  Host  Went  Down  -  A  logically 
addressed  message  was  lost  in  the  network  because 
the  destination  host  to  which  it  was  being 
delivered  went  down.  The  message  should  be 
resubmitted  by  the  source  host,  since  there  may  be 
another  effective  host  port  to  which  the  message 
could  be  delivered  (see  section  2.2.3) . 

Type  10:  Interface  Reset  -  See  1822(3.4). 

Type  11:  Name  Server  Reply  -  This  reply  to  the  Name  Server 
Request  host- to- IMP  message  contains,  following  the 
leader  and  any  leader  padding,  a  word  with  the 
selection  policy  and  the  number  of  physical  addresses 
to  vihich  the  destination  name  maps,  followed  by  two 
words  per  physical  address:  the  first  word  contairiS  an 
182 2L  address,  and  the  second  word  contains  a  bit 
signifying  whether  or  not  that  particular  translation 


(expected  network 


transmission  delay,  in  6.4  ms  units)  to  the  address's 
IMP.  In  figure  3.4,  which  includes  the  leader  without 


eriv  leader  ceddina.  EFF  is  1  for  effective  and  0  for 
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non-effective. 

and  POL  is  a  two- 

•bit  number  indicating 

■ 

the  selection  policy  for  the  name  (see 

section  2.2.2) : 

0:  First  reachable. 

1:  Closest  phys 

leal  address. 

-  y 
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Type  12:  Port  List  Reply  -  Tbis  is  the  reply  to  the  Port 
List  Request  host-to-IMP  message.  It  contains  the 
number  of  names  that  map  to  this  physical  host  port, 
followed  by  two  words  per  name:  the  first  word  contains 
an  182 2L  name  that  maps  to  this  port,  and  the  second 
contains  either  a  zero  or  a  one,  signifying  whether  or 
not  that  particular  translation  is  effective.  The 
format  is  identical  to  the  typ>e  3  NDM  Reply  message 
(see  figure  3.2) . 

Type  15:  1822L  Name  or  Address  Error  -  This  message  is  sent 
in  response  to  a  type  0  message  from  a  host  that 
contained  an  erroneous  Source  Host  or  Destination  Host 
field.  Its  sub- types  are: 

0:  The  Source  Host  1822L  name  is  not  authorized  or  not 
effective. 

1:  The  Source  Host  182 2L  address  does  not  match  the 
host  port  used  to  send  the  message. 

2:  The  Destination  Host  1822L  name  is  not  authorized. 

3:  The  jp^sical  host  to  which  this  singly-homed 
Destination  Host  name  translated  is  authorized  and 
but  not  effective.  If  the  host  was  actually 
down,  a  type  7  message  would  be  returned,  not  a 
type  15. 

5;  The  multi -honied  Destination  Ho.st  name  Is  authorized. 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1985 


182 2L  Host  Access  Protocol  December  1983 

RFC  878 


but  has  no  available  effective  translations. 

6:  A  logically- addressed  uncontrolled  packet  was  sent 
to  a  dead  or  non-effective  host  port.  However,  if 
it  is  resubmitted,  there  may  be  another  effective 
host  port  to  which  the  IMP  may  be  able  to  attempt 
to  send  the  packet. 

7:  Logical  addressing  is  not  in  use  in  this  network. 
8-15:  Unassigned. 

Types  4,13-14,16-255:  Unasslgned. 

Bits  33-48:  Source  Host: 

For  type  0  messages,  this  field  contains  the  1822L  name  or 
address  of  the  host  that  originated  the  message.  All 
replies  to  the  message  should  be  sent  to  the  host  specified 
herein.  For  message  types  5-9  and  15,  this  field  contains 
the  source  host  field  used  in  a  previous  type  0  message  sent 
by  this  host. 

Bits  49-64:  Destination  Host: 

For  type  0  messages,  this  field  contains  the  1822L  name  or 
address  that  the  message  was  sent  to.  This  allows  the 
destination  host  to  detect  how  it  was  specified  by  the 
source  host.  For  message  types  5-9  and  15.  this  field 
contains  the  destination  host  field  used  in  a  previous  type 
0  message  sent  by  this  host, 

-  40  - 
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APPENDIX  A 

1822L-IP  ADDRESS  MAPPINGS 

Once  logical  addressing  Is  In  active  (or  universal)  use  In  a 
network,  to  the  extent  that  the  "official"  host  tables  for  that 
network  specify  hosts  by  their  logical  names  rather  than  by  their 
physical  network  addresses.  It  would  be  desirable  for  hosts  on 
other  networks  to  also  be  able  to  use  the  same  logical  names  to 
specify  these  hosts  when  sending  traffic  to  them  via  the  Internet 
[4]. 

Happily,  there  exists  a  natural  mapping  between  logical  names  and 
Internet  addresses  that  fits  very  nicely  with  the  already 
standard  ARPANET-style  address  mapping  as  specified  In  RFC  796, 
Address  Mappings  [5] .  The  current  ARPANET'Style  class  A  mapping 
Is  as  follows  (from  RFC  796) : 


-  43  - 
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+ - +  + - + - + 

I  HOST  I  I  ZERO  I  IMP  |  1822  Address 

+ - + - + - + 

8  8  8 

+ - + - - 

I  net  #  I  HOST  |  LH  (  IMP  |  IP  Address 

+ - + - + - 4. - + 

8  8  8  8 


1822  Class  A  Mapping 
Figure  A.l 


For  182 2L  names  and  addresses,  the  mapping  would  be:  j 


4-. ---.--4..----. --4. 

I  upper  I  lower  |  182 2L  Name  or  Address 


I  net  #  I  upper  (  LH  )  lower  |  IP  Address 
8  8  8  8 

1822L  Class  A  Mapping 
Figure  A. 2 


For  1822L  addresses,  this  mapping  Is  Identical  to  the  1822 
mapping.  For  182 2L  names,  trie  IP  address  would  appear  to  be 
addressing  a  hlgh'numbered  (64'’255)  1822  host.  Although  the  LH 
(logical  host)  field  Is  still  defined.  Its  use  is  discouraged; 
multiple  logical  names  should  now  be  used  to  multiplex  multiple 
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2.2  Features  of  X.25  not  discussed  in  this  document  are  not  used. 
For  exanple,  interrupt  packets  and  the  D  bit  (indicating 
end-to-end  significance)  are  not  used. 

2.3  Negotiable  features  (facilities)  cf  X.25  are  allowed.  For 
example,  sites  are  free  to  negotiate  larger  packet  and  window 
sizes . 

2.4  Some  sites,  such  as  CSNET  sites,  may  attenpt  to  open  multiple 
virtual  circuits  to  a  single  site.  Sites  should  attempt  to 
handle  such  incoming  calls  gracefully:  transmit  on  the 
additional  circuits  if  possible  and  accept  incoming  datagrams 
from  them,  but  do  not  accept  the  CALL  REQUEST,  only  to 
immediately  close  the  connection  or  ignore  datagrams 
transmitted  on  such  circuits. 
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A  Standard  for  the  Transmission  of  IP  Datagrams 

Over 

Public  Data  Networks 


This  RFC  specifies  a  standard  adopted  by  CST^,  the  VAN  gateway,  and 
other  organizations  for  the  transmission  of  IP  datagrams  over  the 
X.25“based  public  data  networks. 

An  X.25  virtual  circuit  is  opened  on  demand  when  a  datagram  arrives  at 
the  network  interface  for  transmission.  A  virtual  circuit  is  closed 
after  some  period  of  inactivity  (the  length  of  the  period  depends  on 
the  cost  associated  with  an  open  virtual  circuit) .  A  virtual  circuit 
may  also  be  closed  if  the  interface  runs  out  of  virtual  circuits.  An 
algorithm  for  managing  virtual  circuits  during  peak  demand  is  given 
in  [1]. 

STANDARDS 

1.1  The  first  octet  in  the  Call  User  Data  Field  (the  first  data  octet 
in  the  Call  Request  packet)  is  used  for  protocol  demultiplexing. 

The  value  hex  CC  (binary  11001100,  decimal  204)  is  used  to  mean 
INTERNET  PROTOCOL. 

1.2  IP  datagrams  are  sent  as  X,25  "complete  packet  sequences".  That  is, 
datagrams  begin  on  packet  boundaries  and  the  M  bit  ("more  data")  is 
used  for  datagrams  that  are  larger  than  one  packet.  There  are  no 
additional  headers  or  other  data  in  the  packets. 

1.3  Unless  a  larger  packet  size  is  negotiated,  the  maximum  size  of  an 
IP  datagram  transmitted  over  X.25  is  576  octets.  If  two  sites 
negotiate  a  large  X.25  packet  size  (for  example,  1024  octets),  an 
IP  datagram  of  that  size  is  allowed. 

1.4  Either  site  may  close  a  virtual  circuit.  If  the  virtual  circuit  is 
closed  or  reset  while  a  datagram  is  being  transmitted,  the  datagram 
is  lost. 

GENERAL  REMARKS 

2.1  Protocols  above  IP,  such  as  TCP,  do  not  affect  this  standard.  In 
particular,  no  attempt  is  made  to  open  X.25  virtual  circuits 
corresponding  to  TCP  connections. 
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DCN  Local "Network  Protocols 

Ihis  RFC  is  a  description  of  the  protocol  used  in  the  DCN  local 
networks  to  maintain  connectivity,  routing,  and  timekeeping 
information.  These  procedures  may  be  of  interest  to  designers  and 
implementers  of  other  networks. 

1 .  Introduction 

This  document  describes  the  local -net  architecture  and  protocols 
of  the  Distributed  Computer  Network  (DCN) ,  a  family  of  local  nets 
based  on  Internet  technology  and  an  implementation  of  PDPll-based 
software  called  the  Fuzzball.  DCN  local  nets  have  been  in  operation 
for  about  tliree  years  and  now  include  clones  in  the  USA,  UK,  Norway 
and  West  Germany.  They  typically  include  a  number  of  PDPll  or  LSI -11 
Fuzzballs,  one  of  which  is  elected  a  gateway,  and  often  include  other 
Intemet-conpatible  hosts  as  well. 

The  DCN  local -net  protocols  are  intended  to  provide  connectivity, 
routing  and  tim^eeping  functions  for  a  set  of  randomly  connected 
personal  conputers  and  service  hosts.  The  design  philosophy  guiding 
the  Fuzzball  implementation  is  to  incorporate  complete  functionality 
in  every  host,  vhlch  can  serve  as  a  packet  switch,  gateway  and  service 
host  all  at  the  same  time.  When  a  set  of  Fuzzballs  are  connected 
together  using  a  haphazard  collection  of  serial,  parallel  and 
content ion -bus  interfaces,  they  organize  themselves  into  a  network 
with  routing  based  on  minimum  delay. 

The  purpose  of  this  document  is  to  describe  the  local -net 
protocols  used  by  the  DCN  to  maintain  connectivity,  routing  and 
timeke^ing  functions.  The  document  is  an  extensive  revision  and 
e>qpansion  of  Section  4.2  of  [1]  and  is  divided  into  two  parts,  the 
first  of  which  is  an  informal  description  of  the  architecture, 
together  with  explanatory  remarks.  The  second  part  consists  of  a 
semi -formal  specification  of  the  entities  and  protocols  used  to 
determine  connectivity,  establish  routing  and  maintain  clock 
synchronization  and  is  designed  to  aid  in  the  implementation  of  cohort 
systems.  The  link- level  coding  is  described  in  the  appendix. 

2 .  Narrative  Description 

The  DCN  architecture  is  designed  for  local  nets  of  up  to  256 
hosts  and  gateways  using  the  Internet  Protocol  (IP)  and  client 
protocols.  It  provides  adaptive  routing  and  clock  synchronization 
functions  in  an  arbitrary  topology  including  point-to-point  links  and 
multipoint  bus  systems.  It  is  intended  for  use  in  connecting  personal 
computers  to  each  other  and  to  service  machines,  gateways  and  other 
hosts  of  the  Internet  community.  However,  it  is  not  intended  for  use 
in  large,  complex  networks  and  does  not  support  the  sophisticated 
routing  and  control  algorithms  of,  for  example,  the  ARPANET. 

A  brief  description  of  the  process  and  addressing  structure  used 
in  the  DCN  may  be  useful  in  the  following.  A  DCN  physical  host  is  a 
PDPll -compatible  processor  which  supports  a  number  of  cooperating 
sequential  processes,  each  of 
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which  is  given  a  unique  8-bit  identifier  called  its  port  ID.  Every 
DCN  physical  host  contains  one  or  more  internet  processes,  each  of 
which  supports  a  virtual  host  given  a  unique  8 -bit  identifier  called 
its  host  ID. 

Each  virtual  host  can  support  multiple  internet  protocols, 
connections  and,  in  addition,  a  virtual  clock.  Each  physical  host 
contains  a  physical  clock  \dilch  can  cerate  at  an  arbitrary  rate  and, 
in  addition,  a  32-blt  logical  clock  \dilch  operates  at  1000  Hz  and  is 
assumed  to  be  reset  each  day  at  0000  hours  UT.  Not  all  physical  hosts 
lnplement  the  full  32 -bit  precision;  however,  in  such  cases  the 
resolution  of  the  logical  clock  may  be  somewhat  less. 

There  is  a  one-to-one  correspondence  between  Internet  addresses 
and  host  IDs.  The  host  ID  is  formed  from  a  specified  octet  of  the 
iKtemet  address  to  \dilch  is  added  a  specified  offset.  The  octet 
number  and  offset  are  selected  at  configuration  time  and  must  be  the 
same  for  all  DCN  hosts  sharing  the  local  net.  For  class-B  and  class-C 
nets  normally  the  fourth  octet  is  used  in  this  way  for  routing  within 
the  local  net.  In  the  case  of  class-B  nets,  the  third  octet  is 
considered  part  of  the  net  number  by  DCN  hosts;  therefore,  this  octet 
can  be  used  for  routing  between  DCN  local  nets.  For  class-A  nets 
normally  the  third  octet  (ARPANET  logical -host  field)  is  used  for 
routing  where  necessary. 

Each  DCN  physical  host  is  identified  by  a  host  ID  for  the  purpose 
of  detecting  loops  in  routing  updates,  which  establish  the 
minimum-delay  paths  between  the  virtual  hosts.  By  convention,  the 
physical  host  ID  is  assigned  as  the  host  ID  of  one  of  its  virtual 
hosts.  A  link  to  a  nul^por  net  is  associated  with  a  special  virtual 
host,  called  a  gateway,  which  is  assigned  a  unique  host  ID. 

The  links  connecting  the  various  physical  hosts  together  and  to 
foreign  nets  can  be  distributed  in  arbitrary  ways,  so  long  as  the  net 
remains  fully  connected.  If  full  connectivity  is  lost,  due  to  a  link 
or  host  fault,  the  virtual  hosts  in  each  of  the  surviving  segments  can 
continue  to  operate  with  each  other  and,  once  connectivity  is 
restored,  with  all  of  them. 

Datagram  routing  is  determined  entirely  by  internet  address  - 
there  is  no  local  leader  as  in  the  ARPANET.  Each  physical  host 
contains  two  tables,  the  Host  Table,  which  is  used  to  determine  the 
outgoing  liiTk  to  each  other  local -net  host,  and  the  Net  Table,  which 
is  used  to  determine  the  outgoing  host  (gateway)  to  each  other  net. 

The  Host  Table  contains  estimates  of  roundtrip  delay  and  logical -clock 
offset  for  all  virtual  hosts  in  the  net  and  is  Indexed  by  host  ID. 

For  the  purpose  of  conputing  these  estimates  the  delay  and  offset  of 
each  virtual  host  relative  to  the  physical  host  in  which  it  resides  is 
assumed  zero.  The  single  exception  to  this  is  a  special  virtual  host 
associated  with  an  NBS  radio  time-code  receiver,  where  the  offset  is 
conputed  relative  to  the  broadcast  time. 

The  Net  Table  contains  an  entry  for  every  neighbor  net  that  may 
be  connected  to  the  local  net  and,  in  addition,  certain  other  nets 
that  are  not 
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nelg^ibors.  Each  entry  contains  the  net  nimber,  as  well  as  the  host  ID 
of  the  local -net  gateway  to  that  net.  The  routing  function  slsply 
looks  up  the  net  number  In  the  Net  Table,  finds  the  host  ID  of  the 
gateway  and  retrieves  the  port  ID  of  the  net-output  process  from  the 
Host  Table.  Other  Information  Is  Included  In  the  Host  Table  and  Net 
T^le  as  dlscrlbed  below. 

The  delay  and  offset  estimates  are  updated  by  HELLO  messages 
exchanged  on  the  links  connecting  physical -host  neighbors.  The  HELLO 
messages  are  exchanged  frequently,  but  not  so  as  to  materially  degrade 
the  throughput  of  the  link  for  ordinary  data  messages.  A  HELLO 
message  contains  a  copy  of  the  delay  and  offset  Information  from  the 
Host  Table  of  the  sender,  as  %raill  as  Information  to  compute  the 
roundtrlp  delay  and  logical-clock  offset  of  the  receiver  relative  to 
the  sender. 

The  routing  algorithm  Is  similar  to  that  (formerly)  used  In  the 
ARPANET  and  other  places  In  that  the  roundtrlp  (biased)  delay  estimate 
calculated  to  a  neighbor  Is  added  to  each  of  the  delay  estimates  given 
In  Its  HELLO  message  and  compared  with  the  corre^>ondlng  delay 
estimates  In  the  Host  Table.  If  a  delay  computed  in  this  way  Is  less 
than  the  delay  already  In  the  Host  Table,  the  routing  to  the 
corresponding  virtual  host  Is  changed  accordingly.  The  detailed 
operation  of  this  algorithm,  which  Includes  provisions  for  host 
up-down  logic  and  loop  sippresslon.  Is  sunmarlzed  In  a  later  section. 

DCN  local  nets  are  self -configuring  for  all  hosts  aixi  neighbor 
nets;  that  Is,  the  routing  algorithms  will  find  minimum-delay  paths 
between  all  hosts  and  gateways  to  nel^^hbor  nets.  In  addition, 
timekeeping  Information  can  be  exchanged  using  special  HELLO  messages 
between  nel^^iborlng  DCN  local  nets.  For  routing  beyond  neighbor  nets 
additional  entries  can  be  configured  In  the  Net  Tables  as  required. 

In  addition,  a  special  entry  can  be  configured  In  the  Net  Tables  which 
specifies  the  host  ID  of  the  gateway  to  all  nets  not  ejqpllctly 
Included  In  the  table. 

For  routing  via  the  ARPANET  and  Its  reachable  nets  a  selected 
local -net  host  Is  equipped  with  an  IMP  Interface  and  configured  with  a 
OGP/EGP  Gateway  process.  This  proces.s  maintains  the  Net  Table  of  the 
local  host.  Including  ARPANET  leaders,  dynamically  as  part  of  the 
OGP/EGP  protocol  Interactions  with  other  ARPANET  gateways.  OGP/EGP 
protocol  Interactions  are  possibly  with  non-ARPANET  gateways  as  well. 

The  portable  virtual -host  structure  used  In  the  DCN  encourages  a 
rather  loose  Interpretation  of  addressing.  In  order  to  minimize 
confusion  In  the  following,  the  term  'host  ID"  will  be  applied  only  to 
virtual  hosts,  %^lle  "host  number"  will  be  applied  to  the  physical 
host,  called  generlcally  the  DCN  host. 

2.1.  Net  and  Host  Tables 

There  are  two  tables  In  every  DCN  host  which  control  routing  of 
Internet  Protocol  (IP)  datagrams:  the  Net  Table  and  the  Host  Table. 

The  Net  Table  Is  used  to  determine  the  host  ID  of  the  gateway  on  the 
route  to  a  foreign  net. 
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while  the  Host  Table  is  used  to  determine  the  link,  with  respect  to 
the  DCN  host,  on  the  route  to  a  virtual  host.  The  Host  Table  is 
maintained  dynamically  using  updates  generated  by  periodic  HELLO 
messages.  The  Net  Table  is  fixed  at  configuration  time  for  all  DCN 
hosts  except  those  that  support  a  OGP/EGP  Gateway  process.  In  these 
cases  the  Net  Table  is  updated  as  part  of  the  gateway  ^derations.  In 
addition,  entries  in  either  table  can  be  chang^  by  operator  commands. 

The  Net  Table  format  is  shown  in  Figure  1. 

1  0 
5432109876543210 

I  Net  Name  | 

I  Net(2)  I  Net(l)  | 

i  Index  I  Net (3)  | 

I  Hops  I  Gateway  ID  | 

I  I 

I  Gateway  Leader  | 

I  I 

Figure  1.  Not  Table  Entry 

The  “Net  Name"  field  defines  a  short  (RAD50)  name  for  the  net, 
while  the  “Net"  fields  define  the  class  A/B/C  net  mjntomr.  The 
“Gateway  ID"  field  contains  the  host  ID  of  the  first  gateway  to  the 
net  and  the  “Hops"  field  the  number  of  hops  to  it.  The  remaining 
fields  are  used  only  by  the  OGP/EGP  Gateway  process  and  include  the 
“Index"  field,  which  contains  an  index  into  the  routing  matrix,  and 
the  "Gateway  Leader"  field,  which  contains  the  (byte“sw^]ped) 
local “net  leader  for  the  gateway  on  a  nei^ibor  net. 

The  Net  Table  contains  an  indefinite  number  of  entries  and  is 
terminated  by  a  special  entry  with  all  "Net"  fields  set  to  zero.  If 
the  "Hops"  field  of  this  entry  is  less  than  255,  the  "Gate%niy  ID" 
field  of  this  entry  is  used  for  all  nets  not  in  the  table.  If  the 
"Hops"  field  is  255  all  nets  not  explicitly  mentioned  in  the  table 
appear  unreachable. 

The  Host  Table  format  is  sho%ir;  in  Figure  2. 
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1  0 
5432109876543210 


I  TIL  I  Port  ID  I 

I  Delay  | 

I  Offset  I 


Local  Leader 


Ujpdate  Tinestazqp 


Figure  2.  Host  Table  Entry 

The  ordinal  position  of  each  Host  Table  entry  corresponds  to  its 
host  ID.  The  "Nasft^'*  field  contains  a  short  (RAD50)  name  for 
convenient  reference.  The  "Port  ID"  field  contains  the  pert  ID  of  the 
net'output  process  on  the  shortest  path  to  this  virtual  host  and  the 
"Delay"  field  contains  the  Measured  roundtrip  delay  to  it.  The 
"Offset"  field  contains  the  difference  between  the  logical  clock  of 
this  host  and  the  logical  clock  of  the  local  host.  The  "Local  Leader" 
field  contains  information  used  to  construct  the  local  leader  of  the 
outgoing  packet,  for  those  nets  that  require  it.  The  "Update 
Timestaap '  field  contains  the  logical  clock  value  when  the  entry  was 
last  updated  and  the  "TTL"  field  the  time  (in  seconds)  remaining  until 
the  virtual  host  is  declared  down. 

All  fields  except  the  "Name"  field  are  filled  in  as  part  of  the 
routing  update  process,  which  is  initiated  upon  arrival  of  a  HELLO 
message  from  a  neighboring  DCN  host.  This  message  takes  the  form  of 
an  IP  datagram  carrying  the  reserved  protocol  number  63  and  a  data 
field  as  shown  in  Figure  3. 
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1  0 
5432109876543210 

--- 

Fixed  I  Checksum  | 

Area 

I  Date  I 


I  Timestamp  | 
I  Offset  I  Hosts  (n)  | 
I  Delay  Host  0  | 
I  Offset  Host  0  I 


I  Delay  Host  n-1  | 

I  Offset  Host  n-1  | 

Figure  3.  HELLO  Massage  Format 


There  are  two  HELLO  message  formats,  depending  on  the  length  of 
the  message.  One  format,  cent  by  a  DCN  host  to  another  host  on  the 
same  local  net.  includes  both  the  fixed  and  host  areas  shown  above. 

The  second  format,  sent  in  all  other  cases.  Includes  only  the  fixed 

area. 

Note  that  all  word  fields  shown  are  byte-swaoped  with  respect  to 
the  ordinary  POPll  representation.  The  **Checksus^*  field  contains  a 
checksum  cove.-ing  the  fields  indicated.  The  **Date"  and  Time**  fields 
are  filled  in  with  the  local  date  and  time  of  origination.  The 
**Timestaap*'  field  is  used  in  the  computation  of  the  roundtrip  delay 
(see  below)  .  The  **0ffset**  field  contains  the  offset  of  the  block  af 
Internet  addresses  used  by  the  local  net.  The  **Delay  Host  n**  and 
**0ffset  Host  n**  fields  represent  a  copy  of  the  corresponding  entries 
of  the  Host  Table  as  they  exist  at  the  time  of  origination.  The 
**Kosts  (n)**  field  contains  the  number  of  entries  in  this  table. 

2.2.  Roundtrip  Delay  Calculations 

Ps'riodically.  each  DCN  physical  host  sends  a  HELLO  message  to  its 
on  each  of  the  coemunication  llr^js  cowion  to  both  of  th». 

For  each  of  these  links  the  sender  keeps  a  set  of  state  variables, 
including  a  copy  of  the  source -address  field  of  the  last  HELLO  message 
received. 
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When  constructing  a  HELLO  message  the  sender  sets  the 
destination- address  field  to  this  state  variable  and  the 
source- address  field  to  its  own  address.  It  then  fills  in  the  "Date" 
and  "Time"  fields  from  its  logical  clock  and  the  "Timestamp"  field 
from  another  state  variable.  It  finally  copies  the  "Delay"  aid 
"Offset"  values  from  its  Host  Table  into  the  message. 

A  host  receiving  a  HELLO  message  discards  it  if  the  format  is  bad 
or  the  checksum  fails.  If  valid,  it  initializes  a  link  state  variable 
to  show  that  the  lini:  is  up.  Each  time  a  HELLO  message  is  transmitted 
this  state  variable  is  decremented.  If  it  decrements  to  zero  the  link 
is  declared  down. 

The  host  then  checks  if  the  source -address  field  matches  the 
state  variable  containing  the  last  address  stored.  If  not,  the  link 
has  been  switched  to  a  new  host,  so  the  state  variables  are  flushed 
and  the  link  forced  into  a  recovery  state.  The  host  then  checks  if 
the  destination- address  field  matches  its  own  address.  If  so,  the 
message  has  been  looped  (legal  only  in  the  case  of  a  broadcast  net) 
and  the  roundtrip  delay  information  is  corrected.  The  host  and  net 
areas  are  ignored  in  this  case.  If  not,  the  host  and  net  areas  of  the 
message  are  processed  to  update  the  Host  and  Net  Tables. 

Roundtrip  delay  calculations  are  performed  in  the  following  way. 
The  link  input/output  processes  assigned  each  link  maintain  an 
internal  state  variable  which  is  updated  as  each  HELLO  message  is 
received  and  transmitted.  When  a  HELLO  message  is  received  this 
variable  takes  the  value  of  the  "Time"  field  minus  the  current 
time-of-day.  When  the  next  HELLO  message  is  transmitted,  the  value 
assigned  the  "Timestamp"  field  is  conputed  as  the  low-order  16-bits  of 
this  variable  plus  the  current  time-of-day.  The  value  of  this 
variable  is  forced  to  zero  if  either  the  link  is  down  of  the  system 
logical  clock  has  been  reset  since  the  last  HELLO  message  was 
received . 

If  a  HELLO  message  is  received  with  zero  "Timestanp"  field,  no 
processing  other  than  filling  in  the  inteinal  state  variable. 
Otherwise,  the  roundtrip  delay  is  computed  as  the  low-order  16 -bits  of 
the  current  time-of-day  minus  the  value  of  tlJ.s  field.  In  order  to 
assure  the  highest  accuracy,  the  calculation  j performed  only  if  the 
length  of  the  last  transmitted  HELLO  message  (in  octets)  matclies  the 
length  of  the  received  HELLO  message. 

The  above  technique  renders  the  calculation  indej'endent  of  the 
clock  offsets  and  intervals  between  HELLO  messages  at  either  host, 
protects  against  errors  that  mi^t  occur  due  to  lost  HEThO  messages 
and  works  even  when  a  neig^or  host  simply  forwards  the  HEIXO  message 
back  to  the  originator  without  modify'ing  it.  The  latter  behavior, 
typical  of  ARPANET  IMPs  and  gateways,  as  well  as  broadcast  nets,  relys 
on  the  loop -detection  mechanism  so  that  correct  calculations  can  be 
made  and,  furthermore,  that  spurious  host  updates  can  be  avoided. 
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ItMR  a  8^-^^  apTray  arrives  results  in  a  valid  roundtrip 

^Lasf  calcsilatlon.  a  3»st  update  process  is  perforaed.  Hiis  consists 
ori  artdSng  rcnavStrip  delay  to  each  cf  the  "Delay  Host  n**  entries  in 
mssage  m  zasm  and  ocayaring  each  of  these  calculated 
de^^asps  to  the  *Bost  Delay"  field  of  the  corresponding  Host  Table 
ertry.  £a^  entry  is  then  updated  according  to  the  following  rules: 

1  ZS  the  ilstic  connects  to  another  DCN  host  on  the  same  net  and  the 

port  Z^  of  the  link  output  process  Batches  the  "Port  ID" 

field  of  the  entry,  then  qxiate  the  entry. 

2  Zi  the  lick  connects  to  another  DCN  host  on  the  same  net.  the  PID 

cf  the  liTfc  rctptct  process  does  not  Batch  the  "Port  ID"  field  and  the 
calna^i  aeed  delay  is  less  than  die  "Host  Delay"  field  by  at  least  a 
specif  tod  switchir^  threshold  (oLxrently  IOC  Billisec:onds) .  then 
;cpdlBte  the  estsry. 


3f  the  llsdc  connects  to  a  foreiyi  net  and  is  assiyied  a  host  ID 
eainrBjponding  to  the  entry,  then  update  the  entry.  In  this  erase 
use  as  the  calculaced  delay  the  roundtrip  delay. 


«.  if  none  of  the  conditlGns  are  Bet.  or  if  J  f  virtual  host 

has  beer,  rfar  j  aired  dcMo  and  the  ”  ZTV*  field  cxmcaxns  a  nonzero 

vBuuft..  than  no  update  is  perforaed. 

Ihe  •;pcflate  process  consists  of  replacing  the  Delay"  field  with 
tl«  cal^c^latod  delay,  the  "Port  ID"  field  with  the  PID  of  the  link 

process,  the  "I%idate  TiBestaap"  field  with  the  crurrent  time  of 
doH  and  the  "T32L"  field  ty  a  specified  value  (cajrrently  120)  in 
aeonds.  if  the  calcaalareri  delay  exceeds  a  specified  maxianim  interval 
seconds) .  the  virtual  host  is  (Glared  down  by  setting 
tSe  carresgaandf.ng  "Delay"  field  to  the  nax^iaaB  and  the  remaining 
f  ^Ids  as  before.  Fcr  the  purposes  of  delay  calculati:/ns  values  less 
tLan  a  specified  alnijoja  (currently  100  milliseconds)  are  rounded  up 


The  "Dffjaet"  field  is  also  replaced  during  the  update  process. 
Mfcmr.  the  -Elll.  message  arrives.  The  value  of  the  curr^*t  logica?  clock 
is  sjfctrartef  h-oat  the  "TiBe""  field  and  the  difference  added  to 
ane  half  the  . ouridtc’ ip  delay.  The  result! '7  s  r^reser.ts  the 

rffsrr  cf  the  local  ciooc  to  the  clocdc  of  ."^e  serder  _s  .idded  to  the 
c:r*'T«ss»anccri5  'Offset^  '.elf  c.’  tl.c  HEl’ ^  -iiessage  a-'i  ‘  th<=  replaces 
the  ’'If fset"  field  cf  the  i9ost  Table.  Thus.  ti>e  "Offset’  field  in  the 
asst.  Title  for  a  particular  virtual  host  Is  rep’ ^ced  only  if  that  host 
IS  ^  and  Kt  the  miniamai-delay  path  to  the  DCN  r.ost. 

The  piarpcse  of  the  switching  threshold  in  (2)  above  and  the 
delay  specif? cation  in  the  ;pdate  process  is  to  avoid 
ijmecessary  switching  between  links  and  transient  loops  which  can 
r»ccir  tc  rorjtal  variations  in  propagation  delays.  The  purpose  of 
the  ""TTT-'*'  fielo  test  in  (4)  above  is  to  insure  consistantcy  by  purging 
*1*  ra*ths  to  a  yirtca!  host  when  that  virtual  host  ooes  down. 
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In  addition  to  the  updates  performed  as  HELLO  messages  arrive,  each 
virtual  host  in  a  DCN  host  also  performs  a  pjer iodic  update  of  its  own 
Host  Table  entry.  The  update  procedure  is  identical  to  the  above, 
excqpt  that  the  calculated  delay  and  offset  are  taken  as  zero.  At 
least  one  of  the  virtual  hosts  in  a  DCN  host  must  have  the  same  host 
ID  as  the  host  number  assigned  the  DCN  host  itself  and  all  must  be 
assigned  the  same  net  number.  Other  than  these,  there  are  no 
restrictions  on  the  number  or  addresses  of  internet  processes  resident 
in  a  single  DCN  host. 

It  should  be  appreciated  that  virtual  hosts  are  truly  portable 
and  can  migrate  about  the  net,  should  such  a  requirement  arise.  The 
host  update  protocols  described  here  insure  that  the  routing 
procedures  always  converge  to  the  minimum-delay  paths  via  operational 
links  and  DCN  hosts.  In  the  case  of  broadcast  nets  such  as  Ethernets, 
the  procedures  are  modified  slightly  as  described  below.  In  this  case 
the  HELLO  messages  are  used  to  determine  routing  from  the  various 
Ethernet  hosts  to  destinations  off  the  cable,  as  well  as  to  provide 
time  synchronization. 

2.4.  Timeouts 

The  "TTL"  field  in  every  Host  Table  entry  is  decremented  once  a 
second  in  normal  operation.  Thus,  if  following  a  host  uqpdate  another 
update  is  not  received  within  an  interval  corresponding  to  the  value 
initialized  in  that  field,  it  decrements  to  zero,  at  which  point  the 
virtual  host  is  declared  down  and  the  Host  Table  entry  set  as 
described  above.  The  120 -second  interval  used  currently  provides  for 
at  least  four  HELLO  messages  to  be  generated  by  ev'ery  neighbor  on 
every  link  during  that  interval,  since  the  maximum  delay  between  HELLO 
messages  is  30  seconds  on  the  lowest-speed  link  (1200  bps)  .  Thus,  if 
no  HELLO  messages  are  lost,  the  maximum  number  of  links  between  any 
virtual  host  and  any  other  is  four. 

The  “TTL”  field  is  initialized  at  120  seconds  when  an  update 
occurs  and  when  the  virtual  host  is  declared  down.  During  the 
interval  this  field  decrements  to  zero  immediately  after  being 
declared  down,  updates  are  Ignored.  This  provides  a  decent  interval 
for  the  bad  news  to  propagate  throu^out  the  net  and  for  the  Host 
Tables  in  all  DCN  hosts  to  reflect  the  fact.  Thus,  the  formation  of 
routing  loops  is  prevented. 

The  IP  datagram  forwarding  procedures  call  for  decrementing  the 
"time- to -live"  field  in  the  IP  header  once  per  second  or  at  each  point 
where  it  is  forwarded,  whichever  comes  first.  The  value  used 
currently  for  this  purpose  is  30,  so  that  an  IP  datagrram  can  live  in 
the  net  no  longer  than  that  number  of  seconds.  This  is  thus  the 
maximum  delay  allowed  on  any  path  between  two  virtual  hosts.  If  this 
maximum  delay  is  exceeded  in  calculating  the  roundtrip  delay  for  a 
Host  Table  entry,  the  corresponding  virtual  host  will  be  declared 
down . 
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The  Interval  between  HELLO  messages  on  any  link  depends  on  the 
data  rate  supported  by  the  link.  As  a  general  rule,  this  interval  is 
set  at  16  times  the  expected  roundtrip  time  for  the  longest  packet  to 
be  sent  on  that  link.  For  1200-bps  asynchronous  transmission  and 
packet  lengths  to  256  octets,  this  corresponds  to  a  maximum  HELLO 
message  interval  of  about  30  seconds. 

Although  the  roundtrip  delay  calculation,  upon  which  the  routing 
process  depends,  is  relatively  Insensitive  to  net  traffic  and 
congestion,  stochastic  variations  in  the  calculated  values  ordinarily 
occur  due  to  coding  (bit  or  character  stuffing)  and  medium 
perturbations.  In  order  to  suppress  loops  and  needless  path  changes  a 
minimum  switching  threshold  is  incorporated  into  the  routing  mechanism 
(see  above)  .  The  interval  used  for  this  threshold,  as  well  as  for  the 
minimum  delay  on  any  path,  is  100  milliseconds. 

3.  Formal  S^pecificatlon 

The  following  sections  provide  a  formal  framework  which  describe 
tlie  DCN  HELLO  protocol .  This  protocol  is  run  between  neigh^^oring  DCN 
hosts  that  share  a  common  point-to-point  link  and  provides  automatic 
connectivity  determJ.nation,  routing  and  timekeeping  functions. 

The  descriptions  to  follow  are  organized  as  follows:  First  a 
suztinary  of  data  structures  describes  the  global  variables  and  packet 
formats.  Then  rhree  processes  which  liiplement  the  protocol  are 
described:  the  CLOCK,  IIELLO  and  HOST  processes.  The  description  of 
these  processes  is  organized  into  sections  that  describe  (1)  the  local 
variables  used  by  that  process,  (2)  the  parameters  and  constants  and 
(3)  the  events  that  initiate  processing  together  with  the  procedures 
th^  evoke.  In  the  case  of  variables  a  distinction  is  made  between 
state  variables,  which  retain  their  contents  between  procedure  calls, 
and  temporaries,  which  have  a  lifetime  extending  only  while  the 
process  is  running.  Except  as  noted  below,  the  initial  contents  of 
state  variables  are  unimportant. 

3.1.  Data  Structures 

3.1.1.  Global  Variables 
ADESIESS 

This  is  a  32 -bit  bit-string  temporary  variable  used  to  contain  an 

Internet  addre  '^i. 


CLOCK-HID 

This  is  an  eight -bit  integer*  state  variable  used  to  contain  the 
host  ID  of  the  local -net  host  to  be  used  as  the  master  clock.  It 
is  initialized  to  the  appropriate  value  depending  upon  the  net 
configuration. 

DATE 

This  Is  a  16-blt  bit-string  state  variable  used  to  contain  the 
date  in  RT-11  format.  Bits  0-4  contain  the  year,  with  zero 
corresponding  to  1972,  bits  5-9  contain  the  day  of  the  month  and 
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bits  10-14  contain  the  month,  starting  with  one  for  January. 
DATE-VALID 

This  is  a  one-bit  state  variable  used  to  indicate  whether  the 
local  date  and  time  are  synchronized  with  the  master  clock.  A 
value  of  one  indicates  the  local  clock  is  not  synchronized  with 
the  master  clock.  This  variable  is  set  to  one  initially  and  when 
the  local  time-of-day  rolls  over  past  midnigfit.  It  is  set  to  zero 
each  time  a  valid  date  and  time  update  has  been  received  from  the 
master  clock. 

DELAY 

This  is  a  16 -bit  integer  temporary  variable  which  represents  the 
roundtrip  delay  in  milliseconds  to  a  host,. 

HID 

This  is  an  eight-bit  integer  temporary  variable  containing  tl,ie 
host  ID  of  some  hcat  on  the  local  net. 

There  is  a  one-to-one  correspondence  between  the  Internet 
addresses  of  local  hosts  and  their  HIDs.  The  mapping  between  them 
is  selected  on  the  basis  of  the  octet  ntmiber  of  the  Internet 
address.  For  DCN  hosts  it  is  the  fourth  octet,  while  for  hosts 
dir€K:tly  connected  to  a  class-A  ARPANET  IMP  or  gateway,  it  is  the 
third  octet  (logical -host  field) .  The  contents  of  this  octet  are 
to  be  added  to  ADDRESS -OFFSET  to  form  the  KID  associated 
with  the  address. 

HOLD 

This  is  an  ei^t-bit  counter  state  variable  indicating  whether 
timestamps  are  valid  or  not.  While  HOLD  is  nonzero,  timestamps 
should  be  considered  invalid.  When  set  to  some  nonzero  value,  the 
counter  decrements  to  zero  at  a  1-Hz  rate.  Its  initial  value  is 
zero. 

HOST-TABLE 

This  is  a  table  of  NHOSTS  entries  indexed  by  host  ID  (HID)  .  There 
is  one  entry  for  each  host  in  the  local  net.  Each  entry  has  the 
following  format: 

HOST-TABLE. DELAY 

This  is  a  16-blt  field  containing  the  computed  roundtrip  delay 
in  milliseconds  to  host  HID. 

HOST-TABLE . OFFSET 

This  is  a  16-blt  field  containing  the  conputed  signed  offset 
in  milliseconds  which  must  be  added  to  the  local  apparent 
clock  to  agree  with  the  apparent  clock  of  host  HID. 

HOST-TABLE.  PID 

This  is  an  eight -bit  field  containing  the  PID  of  the  net-output 
process  selected  by  the  routing  algorithm  to  forward  packets 
to  host  HID. 
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HOST-TABLE.  TTL 

This  is  an  eigfit-bit  field  usea  as  a  time-to-live  indicator. 

It  is  decremented  by  the  HOST  process  once  each  second  and 
initialized  to  a  chosen  value  when  a  HELLO  message  is 
received.  The  table  is  initialized  with  the  HOST-TABLE. DELAY 
field  set  to  MAXDELAY  for  all  entries.  The  contents  of  the 
other  fields  are  uninportant . 

LOCAL -ADDRESS 

This  is  a  32 -bit  bit-string  state  varialile  used  to  contain  the 
local  host  Internet  address. 

NET-TABLE 

This  is  a  table  of  NNETS  entries  with  the  following  format: 
NET-TABLE. HID 

This  is  an  eight -bit  field  containing  the  host  ID  of  the 
pseudo -process  to  forward  packets  to  the  NET-TABLE.NET  net. 

NET-TABLE.NET 

This  is  a  24-bit  field  containing  an  Internet  class -A  (eight 
bits),  class-B  (16  bits)  or  class-C  (24  bits)  net  number. 

Note  that  the  actual  field  width  for  class-B  n^t  numbers  is  24 
bits  in  order  to  provide  a  subnet  capability,  ir.  which  the 
hi^- order  eig^t  bits  of  the  16 -bit  host  address  is 
interpreted  as  the  subnet  number. 

The  table  is  constructed  at  configuration  time  and  must  include  an 
entry  for  every  net  that  is  a  potential  neighbor.  A  neighbor  net 
is  defined  as  a  net  containing  a  host  that  can  be  directly 
connected  to  a  host  on  the  local  net.  The  entry  for  such  a  net  is 
initialized  with  NET-TABLE.NET  set  to  the  neighbor  net  number  and 
NET-TABLE. HID  set  to  an  arbitrary  vitual-host  ID  not  assigned  any 
other  local -net  virtual  host. 

The  remaining  entries  in  NET-T/kBLE  are  initialized  at  initial -boot 
time  With  tlie  NET-TABLE.NET  fields  set  to  zero  and  the 
NET-TABLE  .HID  fields  set  to  a  configuration-selected  host  ID  to  be 
used  to  forward  packet.s  to  all  nets  other  than  neig^ibor  nets.  In 
the  case  where  a  gateway  module  is  included  in  the  local  host 
configuration,  the  OGP  and/or  EGP  protocols  will  be  used  to 
malntian  these  entries;  ^^le,  in  tlie  case  where  no  gateway 
module  is  included,  only  one  such  entry  is  required. 

OFFSET 

This  is  a  16 -bit  signed  Integer  temporary  variable  whicn 
represents  the  offset  in  milliseconds  to  be  added  to  the  apparent 
clock  time  to  yield  the  apparent  clock  time  of  the  neighbor  host, 

3.1.2.  Parameters 

ADDRESS-OFFSET 

This  is  an  Integer  which  represents  the  value  of  the  Internet 
address  field  corresponding  to  the  first  host  in  HOST-TABLE. 
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NHOSTS 

Hiis  is  an  integer  which  defines  the  number  of  entries  in  HOST-TABLE. 
NNETS 

This  is  an  Integer  which  defines  the  number  of  entries  in  MET-TABLE. 
3.1.3.  HELLO  Packet  Fields 
PKT .ADDRESS-OFFSET 

This  eic^t-bit  is  copied  from  ADDRESS -OFFSET  by  the  sender. 

PKT.DATESTAMP 

Bits  0-14  of  this  16 -bit  field  are  copied  from  DATE  by  the  sender, 
while  bit  15  is  copied  from  DATE-VALID. 

PICT .  DATE-VALID 

This  one-bit  field  is  bit  15  of  PKT.DATESTAMP. 

PKT. DESTINATION 

This  32-bit  field  is  part  of  the  IP  header.  It  is  copied  from 
HLO. NEIGHBOR -ADDRESS  by  the  sender. 

PKT. HOST-TABLE 

This  is  a  table  of  PKT. NHOSTS  entries,  each  entry  of  vhich 
consists  of  two  fields.  The  entries  are  indexed  by  host  ID  and 
have  the  following  format: 

PKT .  HOST-TABLE .  DELAY 

This  16 -bit  field  is  copied  from  the  corresponding  HOST-TABLE. DELAY 
field  by  the  sender. 

PKT .HOST-TABLE . OFFSET 

This  16-bit  field  is  copied  from  the  corresponding  HOST-TABLE . OFFSET 
field  by  the  sender. 

PKT.LEN'GTH 

This  16-bit  field  is  part  of  the  IP  header.  It  is  set  by  the  sender  to 
the  number  of  octets  in  the  packet. 

PKT.  NHOSTS 

This  eig^t-bit  field  is  copied  from  NHOST  by  the  sender. 

PKT. SOURCE 

This  16-blt  field  is  part  of  the  IP  header.  It  is  copied  from 
LOCAL -ADDRESS  by  the  sender. 

PKT.  TIMESTAMP 

This  32 -bit  field  contains  the  apparent  time  the  packet  was  transmitted 
in  milliseconds  past  midnight  UT. 
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PKT.TSP 

Uiis  16 -bit  field  contains  a  variable  used  in  roundtrip  delay 
calculations . 

3.2  CLOCK  Process  (CLK) 

The  tim^eeping  system  maintains  three  clocks:  (1)  the  physical 
clock,  v^ch  is  determined  by  a  hardware  oscillator/counter;  (2)  the 
ajparent  clock,  which  maintains  the  time-of-day  used  by  client 
processes  and  (3)  the  actual  clock,  which  represents  the  time-of-day 
provided  by  an  outside  reference.  The  apparent  and  actual  clocks  are 
maintained  as  48-bit  quantities  with  32  bits  of  significance  available 
to  client  processes.  These  clocks  run  at  a  rate  of  1000  Hz  and  are 
reset  at  midni^t  UT. 

The  CLOCK  process  consists  of  a  set  of  state  variables  along  with 
a  set  of  procedures  that  are  called  as  the  result  of  hardware 
interrupts  and  client  requests.  An  interval  timer  is  assumed 
logically  separate  from  the  local  clock  mechanism,  although  both  could 
be  derived  from  the  same  timing  source. 

3.2.1.  Local  Variables 

CLK. CLOCK 

Ihis  is  a  48 -bit  fixed -point  state  variable  used  to  represent  the 
apparent  time-of-day.  The  decimal  point  is  to  the  rig^t  of  bit  16 
(numbering  from  the  right  at  bit  0)  .  Bit  16  increments  at  a  rate 
equivalent  to  1000  Hz  ind^jendent  of  the  hardware  clock.  (In  the 
case  of  programmable-clock  hardware  the  value  of  CLK. CLOCK  must  be 
corrected  as  described  below.) 

CLK. COUNT 

This  is  a  hardware  register  that  increments  at  rate  R.  It  can  be 
represented  by  a  simple  line  clock,  which  causes  interrupts  at  the 
line- frequency  rate,  or  by  a  programmable  clock,  \^ch  contains  a  16-bit 
register  that  is  programmed  to  count  at  a  1000 -Hz  rate  and  causes  an 
interrupt  on  overflow.  The  register  is  considered  a  fixed-point  variable 
with  decimal  point  to  the  ri^t  of  bit  0. 

CLK. DELTA 

This  is  a  48 -bit  signed  fixed-point  state  variable  used  to  represent  the 
increment  to  be  added  to  CLK. CLOCK  to  yield  the  actual  time-of-day.  The 
decimal  point  is  to  the  ri^t  of  bit  16. 

3.2.3.  Parameters 

ADJUST-FRACTION 

This  is  an  integer  which  defines  the  shift  count  used  to  conpute  a 
fraction  that  is  used  as  a  multiplier  of  CLK. DELTA  to  correct  CLK. CLOCK 
once  each  clock-adjust  interval.  A  value  of  seven  is  suggested. 
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ADJUST- INTERVAL 

This  is  an  integer  which  defines  the  clock- adjust  interval  in 
milliseconds.  A  value  of  500  (one-half  second)  is  suggested  for 
the  line  clock  and  4000  (four  seconds)  for  the  1000-Hz  clock. 

CLCX3C-TiaC 

This  is  a  fixed-point  integer  which  defines  the  increment  in 
milliseconds  to  be  added  to  CLK.CLCXIK  as  the  result  of  a  clock 
tick.  The  decimal  point  is  to  the  rig^t  of  bit  16.  In  the  case 
of  a  line-clock  interrupt,  the  value  of  CLOCK-TICK  ^ould  be 
16.66666  (60  Hz)  or  20.00000  (50  Hz).  In  the  case  of  a  1000-Hz 
programmable-clock  overflow,  the  value  ^ould  be  65536.00000. 

HOLD- INTERVAL 

This  is  an  integer  i^iich  defines  the  number  of  seconds  that  HOLD  will 
count  down  after  CLK. CLOCK  has  been  reset.  The  resulting  interval  must  b< 
at  least  as  long  as  the  maximum  HELLO- INTERVAL  used  by  any  HELLO  process. 

3.2.3.  Events  and  Procedures 

INCREMENT-CLOCK  Event 

This  event  is  evoked  as  the  result  of  a  tick  internet,  in  the  case  of  a 
line  clock,  or  a  counter  overflow,  in  the  case  of  the  1000-Hz  clock.  It 
causes  the  logical  clock  to  be  incremented  by  the  value  of  CLOCK-TICK. 

1.  Add  the  value  of  CLOCK-TICK  to  CLK. CLOCK. 

ADJUST-CLOCK  Event 

This  event  is  evoked  once  every  ADJUST- INTERVAL  milliseocnds  to  slew  the 
apparent  clock  time  to  the  actual  clock  time  as  set  by  the  SET-CLOCK 
procedure.  This  is  done  by  subtracting  a  fraction  of  the  correction 
factor  CLK. DELTA  from  the  value  of  CLK. DELTA  and  adding  the  same  fraction 
to  CLK. CLOCK.  This  continues  until  either  the  next  SET-CLOCK  call  or 
CLK. DELTA  has  been  reduced  to  zero. 

The  suggested  values  for  ADJUST- INTERVAL  and  ADJUST-FRACTION 
represent  a  maximum  slew  rate  of  less  than  +-2  milliseconds  per 
second,  in  the  case  of  1000-Hz  clock.  The  action  is  to  smooth 
noisy  clock  corrections  received  from  neighboring  systems  to 
obtain  a  hi^-quality  local  reference,  while  insuring  the  apparent 
clock  time  is  always  monotonically  increasing. 

1.  Shift  the  48-bit  value  of  CLK. DELTA  arithmetically  ADJUST -FRACTION 
bits  to  the  rig^t,  discarding  bits  from  the  right  and  saving  the 
result  in  a  tenporary  variable  F.  Assuming  the  decimal  point  of  F  to 
be  positioned  to  the  right  of  bit  16  and  sign -extending  as  necessary, 
subtract  F  from  CLK. DELTA  and  add  F  to  CLK. CLOCK. 
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DECREMENT-HOLD  Event 

•niis  event  is  evoked  once  per  second  to  decrement  the  value  of  HOLD. 

1.  If  the  value  of  HOLD  is  zero,  do  nothing;  otherwise,  decrement  its 
value. 

READ- CLOCK  Procedure 

Ihis  procedure  is  called  by  a  client  process.  It  returns  the  apparent 
time-of-day  conputed  as  the  integer  part  of  the  sum  CLK. CLOCK  plus 
CLK. COUNT.  Note  that  the  precision  of  the  value  returned  is  limited  to 
+-1  millisecond,  so  that  client  processes  must  expect  the  apparent 
time  to  "run  backward"  occasionally  due  to  drift  correctins.  When 
this  happens  the  backward  step  will  never  be  greater  than  one 
millisecond  and  will  never  occur  more  often  than  twice  per  second. 

1.  In  the  case  of  line  clocks  CLK. COUNT  is  always  zero,  while  in 
the  case  of  programmable  clocks  the  hardware  must  be 
interrogated  to  extract  the  value  of  CLK. COUNT.  If  following 
interrogation  a  counter -over flow  condition  is  evident,  add 
CLOCK-TICK  to  CLK. CLOCK  and  interrogate  the  hardware  again. 

2.  When  the  value  of  CLK. COUNT  has  been  determined  conpute  the  sum 
CLK. COUNT  +  CLK. CLOCK.  If  this  sum  exceeds  the  number  of 
milliseconds  in  24.  hours  (86,400,000),  reduce  CLK. CLOCK  by 
86,400,000,  set  HOLD-INTERVAL  ->  HOLD,  set  CLOCK-VALID  (bit  15 
of  DATE)  to  one,  roll  over  DATE  to  the  next  calender  day  and 
start  over.  If  not,  return  the  integer  part  of  the  sum  as  the 
apparent  time-of-day. 

Ihe  CLOCK-VALID  bit  is  set  to  insure  that  a  master-clock  upxiate  is 
received  at  least  once  p>er  day.  Note  that,  in  the  case  of 
uncompensated  crystal  oscillators  of  the  typ>e  commonly  used  as  the 
1000-Hz  time  base,  a  drift  of  several  parts  per  million  can  be 
expjected,  which  would  result  in  a  time  drift  of  several  tenths  of  a 
second  per  day,  if  not  corrected. 

SET-CLOCK  Procedure 

This  procedure  is  called  by  a  client  process.  It  sets  a  time-of-day 
correction  factor  in  milliseconds.  The  argument  represents  a  32-bit 
signed  fixed-point  quantity  with  decimal  point  wO  the  right  of  bit 
0  that  is  to  be  added  to  CLK.  CLOCK  so  that  READ -CLOCK  subsequently 
returns  the  actual  time-of-day. 

1.  If  the  correction  factor  is  in  the  range  -2** (16 -AD JUST-FRACTION)  to 
+2**  (16-ADJUST-FRACTION)  -  1  (about  +-128  milliseconds  with  the 
suggested  value  of  ADJUST -FRACTION) ,  the  value  of  the  argument 
replaces  CLK. DELTA  and  the  procedure  is  conpiete.  If  not,  add  the 
value  of  the  sign-extended  argument  to  CLK. CLOCK  and  set  CLK. DELTA  to 
zero.  In  addition,  set  HOLD- INTERVAL  ->  HOLD,  since  this 
represents  a  relatively  large  step-change  in  apparent  time. 

The  value  of  HOLD  r^resents  the  remaining  number  of  seconds 
in  which  timestanps  should  be  considered  invalid  and  is  used 
by  the  HELLO  process  to  suppress  roundtrlp  delay  calculations 
which  mi^t  involve  invalid  timestanps. 
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3.3.  HELLO  Process 

The  HELLO  process  maintains  clock  synchronization  with  a  neighbor 
HELLO  process  using  the  HELLO  protocol.  It  also  participates  in  the 
routing  algorithm.  There  is  one  HELLO  process  and  one  set  of  local 
state  variables  for  each  link  connecting  the  host  to  one  of  its 
neicfibors . 

3.3.1.  Local  variables 
HLO. BROADCAST 

This  is  a  one“bit  switch  state  variable.  When  set  to  zero  a 
point-to-point  link  is  assumed.  When  set  ot  one  a  broadcast  (e.g. 
Ethernet)  link  is  assumed. 

HLO. KEEP-ALIVE 

Ihis  is  an  eigfit-bit  counter  state  variable  used  to  indicate  whether  the 
link  is  qp.  It  is  initialized  with  a  value  of  zero. 

HLO.  LENGTH 

This  is  a  16-bit  integer  state  variable  used  to  record  the  length  in 
octets  of  the  last  HELLO  message  sent. 

HLO  .NEIGHBOR- ADDRESS 

This  is  a  32 -bit  integer  state  variable  used  to  contain  the  nei^ibor  host 
Internet  address. 

HLO.PID 

This  is  an  eight -bit  integer  state  variable  used  to  identify  the 
net-output  process  associated  with  this  HELLO  process.  It  is  initialized 
by  the  kernel  \dien  the  process  is  created  and  remains  xinchanged 
thereafter. 

HLO. POLL 

This  is  a  one-bit  switch  state  variable.  When  set  the  HELLO  process 
spontaneously  sends  HELLO  messages.  When  not  set  the  HELLO  process 
responds  to  HELLO  messages,  but  does  not  send  them  spontaneously. 

HLO.TIMEST’AMP 

This  is  a  32-bit  integer  temporary  variable  used  to  record  the  time  of 
arrival  of  a  HELLO  message. 

HLO.TSP 

This  is  a  16-bit  signed  integer  state  variable  used  in  roundtrip  delay 
calculations. 
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3.3.2.  Parameters 
HELLO- INTERVAL 

Tills  is  an  integer  which  defines  the  interval  in  seconds  between  HELLO 
messages.  It  ranges  from  about  eight  to  a  maximum  of  30  seconds, 
depending  on  line  speed. 

HOLD-DOWN- INTERVAL 

This  is  an  integer  which  defines  the  inten/al  in  seconds  a  host  will  be 
considered  up  following  receipt  of  a  HELLO  message  indicating  that 
host  is  up.  A  value  of  120  is  suggested. 

KEEP -ALIVE- INTERVAL 

This  is  an  integer  which  defines  the  interval,  in  units  of 
HELLO- INTERVAL,  that  a  HELLO  process  will  consider  the  link  up.  A 
value  of  four  is  suggested. 

MAJQDELAY 

This  is  an  integer  which  defines  the  maximum  roundtrip  delay  in 
seconds  on  a  path  to  any  reachable  host.  A  value  of  30  is  suggested. 

MXNDELAY 

This  is  an  integer  vhich  defines  the  minimum  switching  threshold  in 
milliseconds  below  which  routes  will  not  be  changed.  A  value  of  100  is 
suggested. 

3.3.3.  Events  and  Procedures 
INPUT-PACKET  Event 

When  a  packet  arrives  the  net- input  process  first  sets  HLO. TIMESTAMP  to 
the  value  returned  by  the  READ -CLOCK  procedure,  then  checks  the 
packet  for  valid  local  leader,  IP  header  format  and  checksum.  If 
the  protocol  field  in  the  IP  header  Indicates  a  HELLO  message,  the 
packet  is  passed  to  the  HELLO  process.  If  any  errors  are  found 
the  packet  is  dropped. 

The  HELLO  process  first  checks  the  packet  for  valid  HELLO  header  format 
and  checksum.  If  any  errors  are  found  the  packet  is  dropped.  Otherwise, 
it  proceeds  as  follows: 

1.  If  PKT. SOURCE  is  equal  to  LOCAL -ADDRESS,  then  the  line  to  the 
neighbor  host  is  looped.  If  this  is  a  broadcast  link 

(HLO . BROADCAST  is  set  to  one),  then  ignore  this  nicety;  if 
not,  this  is  considered  an  error  and  further  processing  is 
abandoned.  Note  that,  in  special  configurations  involving 
other  systems  (o.g.  ARPANET  IMPs  and  gateways)  it  may  be 
useful  to  use  looped  HELLO  to  monitor  connectivity.  The  DCN 
implementation  provides  this  feature,  but  is  not  described  hero. 

2.  Set  KEEP-ALIVE- INTERVAL  ->  HLO. KEEP-ALIVE.  This  indicates  the 
maximum  number  of  HELLO  Intervals  the  HLO.'fSP  field  is 
considered  valid. 
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3.  Set  PKT. TIMESTAMP  -  HLO. TIMESTAMP  ->  HLO.TSP.  This  is  part  of  the 
roundtrlp  delay  calculation.  The  value  of  HLO.TSP  will  be 
updated  and  returned  to  the  nel^^ibor  In  the  next  HELLO  message 
tranmltted.  Next,  conpute  the  raw  roundtrlp  delay  and  offset: 

HLO. TIMESTAMP  -  PKT.TSP  ->  DELAY  and  HLO.TSP  +  DELAY/2  ->  OFFSET. 
Note:  in  the  case  of  a  broadcast  link  (HLO . BROADCAST  set  to  one)  set 
DELAY  to  zero. 

4.  Perform  this  step  only  In  the  case  of  non-broadcast  links 
(HLO. BROADCAST  set  tc  zero)  .  If  PICT. SOURCE  Is  not  equal  to 
HLO.NEIGHBOR-ADDRESS,  then  a  new  nel^^ibor  has  appeared  on  this 
link.  Set  PKT. SOURCE  ->  HLO. NEIGHBOR  ADDRESS,  MAXDELAY  -> 

DELAY  and  proceed  to  'he  next  step.  This  will  force  the  line 
to  be  declared  do%m  and  res^t  In  a  hold-down  cycle. 

Otherwise,  If  either  PKT.TSP  Is  zero  or  HOLD  Is  nonzero,  then 
thB  DELAY  calculation  Is  Invalid  and  further  processing  Is 
abandoned.  Note  that  a  hold-down  cycle  Is  forced  In  any 
case  If  a  new  nei^^r  Is  recognized. 

5.  If  processing  reaches  this  point  the  DELAY  and  OFFSET 
variables  can  be  assumed  valid  as  well  as  the  remaining  data 
In  the  packet.  First,  If  DELAY  <  MINDELAY,  set  MINDELAY  -> 

DELAY.  This  avoids  needless  path  switching  whcm  the 
difference  In  delays  Is  not  significant  and  has  the  effect 
that  on  low-delay  links  the  routing  algorithm  degenerates  to 
mln-hop  rather  than  min-delay.  Then  set  HLO.PID  ->  PID.  There  are 
two  cases: 

Case  1:  PKT.NHDSTS  Is  zero. 

This  will  be  the  case  when  the  nel^^hbor  host  has  just  come  up  or 
Is  on  a  different  net  or  subnet.  Set  NEIGHBOR-ADDRESS  ->  ADDRESS 
and  call  the  ROUTE  procedure,  %<hlch  will  return  the  host 
ID.  Then  call  the  UPDATE  procedure.  In  the  case  of 
errors,  do  nothing  but  return. 

Case  2:  PKT.NHOSTS  Is  nonzero. 

This  Is  the  case  when  the  nel^^ibor  host  Is  on  the  same  net  or 
subnet.  First,  save  the  values  of  DELAY  and  OFFSET  In  tenporary 
variables  F  and  C.  Then,  for  each  vali;e  of  HID  from  zero  to 
NHOSTS-1  consider  the  corresponding  PKT. HOSTS -TABLE  entry  and  do 
the  following:  Set  F  ♦  PKT. HOST-TABLE. DELAY  ->  DELAY  and 
C  ♦  PKT. HOST-TABLE. OFFSET  ->  OFFSET  and  call  the  UPDATE  procedure 
This  completes  processing. 

ROUTE  Procedure 

This  procedure  returns  the  host  ID  in  HID  of  th'.%  host  represented 
by  the  global  variable  ADDRESS. 

1.  First,  determine  if  the  host  represented  b^*  ADDRESS  Is  on  the  same 
local  net  as  LOCAL -ADDRESS.  For  the  purposes  of  this 
comparison  bits  0-7  wnd  16-31  are  compared  for  class- A  nets 
and  bits  8-31  are  compared  for  class-B  and  cl  «ss-C  nets.  This 
provides  for  a  subnet  capability,  where  the  bits  0-7  and  16-23 
(class-A)  or  8-15  (class-B)  are  used  as  a  subr>et  number. 


DDN  PROTOCOL  HANDBOOK  -  VOLL^E  THREE 


1985 


DCN  Local -Network  Protocols  Page  20 

D.L.  Mills 


Case  1:  The  host  is  on  the  same  net  or  subnet. 

Extract  the  address  field  of  AI^SRESS,  subtract  ADDRESS -OFFSET  and 
store  the  result  in  HID.  If  0  <=  HID  <  NHOSTS,  the  procedure 
coiqpletes  normally;  otherwise  it  terminates  in  an  error 
condition . 

Case  2:  The  host  is  not  on  the  same  net  or  subnet. 

Search  the  NET-TABLE  for  a  match  of  the  net  fields  of 
LOCAL -ADDRESS  and  NET-TABLE.NET.  If  found  set 
NET-TABLE.HID  ->  HID  and  return  normally.  If  the  NET-TABLE.NET 
field  is  zero,  indicating  the  last  entry  in  the  table,  set 
HET-TABLE.HID  ->  HID  and  return  normally.  Note  that,  in  the  case 
of  hosts  including  OGP/EGP  gateway  modules,  if  no  match  is  found 
the  procedure  terminates  in  an  error  condition. 

UPDATE  Procedure 

This  procedure  updates  the  entry  of  HOST-TABLE  ixvlicated  by  HID  using 
three  global  variables:  DELAY,  OFFSET  and  PID.  Its  purpose  is  to  u^ate 
the  HOST-TABLE  entity  corresponding  to  host  ID  HID.  In  the  following  all 
references  are  to  this  entry. 

1.  If  PID  is  not  equal  to  HOST-TABLE. PID,  the  route  to  host  HID  is  not 
via  the  net- outfit  process  associated  with  this  HELLO  process.  In 
this  case,  if  DELAY  ♦  KINDELAY  >  HOST -TABLE. DELAY,  the  path  is  longer 
than  one  already  in  HOST-TABLE,  so  the  procedure  does  nothing. 

2.  This  step  is  reached  only  if  either  the  route  to  host  HID  is  via  the 
net-output  process  associated  with  this  HELLO  process  or  the  newly 
reported  path  to  this  host  is  shorter  by  at  least  MINDELAY. 

There  are  two  cases: 

Case  1:  HOST-TABLE. DELAY  <  MAXDELAY. 

The  existing  path  to  host  HID  is  up  and  this  is  a  point-to-point 

link  (HLO. BROADCAST  is  set  to  zero)  .  If  DEL.AY  <  MAXDELAY  the 

newly  reported  path  is  also  up.  Proceed  to  the  next  step. 

Otherwise,  initiate  a  hold-down  cycle  by  setting 

MAXDELAY  ->  HOST-TABLE. DELAY  and 

HOLD-DOWN- INTERVAL  ->  HOST- TABLE. TTL  and  return. 

Case  2:  HOST -TABLE. DELAY  >=  MAXDELAY. 

The  existing  path  to  host  HID  is  down.  If  DELAY  <  MAXDELAY  and 
HOST-TABLE. TTL  is  zero,  the  hold-down  period  has  expired  and  the 
newly  reported  path  has  just  come  up.  Proceed  to  the  next  step. 
Otherwise  siaply  return. 

3.  In  this  step  the  HOST-DELAY  entry  is  ^xiated.  Set 

DELAY  ->  HOST-TABLE. DELAY,  HOLD-DOWN- I NTERVAL  ->  HOST -TABLE .TTL  and 
HLO. PID  ->  HOST-TABLE. PID. 
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4.  For  precise  timekeeping,  the  offset  can  be  considered  valxd  only  if 
the  length  of  the  last  HELLO  packet  transaltted  is  equal  to 
the  length  of  the  last  one  received.  Thus,  if  HLX>.I.£NCnE 
equal  to  PKT. LENGTH,  set  OFFSET  ->  HOST-TABLE. OEl^ET; 
otherwise,  leave  this  field  alone.  Finally,  if  HID  is  eqiaal  to 
CLOCK-HID  and  bit  15  (the  DATE-VALID  bit) 

of  DATE  is  zero,  set  PKT.DATESIAH>  ->  DATE  and  call  tJae  SET-CSjOCZ 
procedure  of  tlic  CLOCK  process  with  argiMcnt  HLO  TMISIAI®- 

OUTPUT-PACKET  Event  _ 

This  event  is  evoked  once  every  HELLO- INTOtVAL  seconds.  It  deter»ls*s  i 
a  HELLO  message  is  to  be  transmitted,  transmits  it  and  ^pdat)es  state 
variables . 

1.  If  HLO. KEEP -ALIVE  is  nonzero  decrement  its  value. 

2.  If  HLO. POLL  is  zero  and  HLO. KEEP -ALIVE  is  zero,  do  not  send  a  milZ 
message.  If  either  is  nonzero  initialize  the  packet  fields  as 
follows:  LOCAL-AE«»ESS  ->  PKT.SOWCE, 

HLO. NEIGHBOR- AEOKESS  ->  PKT.DErnNAIl  H  and  DATE  ->  PK7-aKI£S2IW. 
Note:  PKT.DESTINATICXf  is  set  to  zero  if  this  is  a  broademst  llsific 
(HLO. BROADCAST  set  to  one)  .  Also,  note  tiiat  bit  15  of  DRCE  is  the 
DATE-VALID  bit.  If  this  bit  is  one  the  receiver  will  not  iqpdiate  its 
master  clock  from  the  information  in  the  transmitted  pactet. 

This  is  significant  only  if  the  sending  host  is  on  the 
least-delay  path  to  the  master  clock.  Set  FKT.TTICSTMP  to 
the  value  returned  from  the  READ-QjOCK  procedure-  If 
HLO. KEEP -ALIVE  is  zero  or  IK)Ii>  is  ncxizero,  set  PKT.TSP  to 
zero;  otherwise,  set  PKT. TIMESTAMP  ♦  HLO.TSP  ->  PKT.TSP. 

3.  Determine  if  the  neighbor  is  on  the  same  net  or  sdbnet.  If  the 
neic^or  is  on  a  different  net  set  PfCT.mOSTS  to  zero  and 
proceed  with  the  next  st^.  Otherwise,  set  IBOSTS  -> 

PKT.NHOSTS  and  for  each  value  of  HID  from  zero  to  PKT-BDSIS-l 
copy  the  HOST-TABLE. DELAY  and  HOST-TABLE. OFFSET  fields  ©f  tSae 
corresponding  HOST-TABLE  entry  in  order  into  the  packet.  Fear 
each  entry  copied  test  if  the  HOST-TABLE. PID  field  marrher  the 
HLO.PID  of  the  HELLO  process.  If  so,  a  potential  routing  loop 
Is  possible.  In  this  case  use  MAXDELAY  for  the  delay  field  in 
the  packet  instead. 

4.  Finally,  set  HLO. LENGTH  to  the  nunber  of  octets  in  the  packet 
and  send  the  packet. 

3,4.  HOST  Process  (HOS) 

This  process  maintains  the  routing  tables.  It  is  activated  once  pe.- 
second  to  scan  HOST-TABLE  and  decrement  the  HCST-TABLE.TH.  field  af  each 
entry.  It  also  performs  houseke^ing  functions. 
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Appendix  A.  Link-Level  Packet  Formats 

A.l.  Serial  Links  Using  Program- Interrupt  Interfaces 

Following  is  a  description  of  the  frame  format  used  on 
asynchronous  and  synchronous  serial  links  with  program- interrupt 
interfaces  such  as  the  DEC  DLVll  and  DPVll.  This  format  provides 
transparency  coding  for  all  messages,  including  HELLO  messages,  but 
does  not  provide  error  detection  or  retransmission  functions.  It  is 
designed  to  be  easily  Implemented  and  conpatible  as  far  as  possible 
with  standard  industry  protocols. 

The  protocol  is  serial-by-bit,  with  the  same  interpretation  on 
tlje  order  of  transmission  as  standard  asynchronous  and  synchronous 
interface  devices;  that  is,  the  low-order  bit  of  each  octet  is 
transmitted  first.  The  data  portion  of  the  frame  consists  of  one 
Internet  datagram  encoded  according  to  a  "character-stuffing" 
transparency  convention: 

1.  The  frame  begins  with  the  two-octet  sequence  DLE-STX,  in  the  case  of 
asynchronous  links,  or  the  four-octet  sequence  SYN-SYN-DLE-STX,  in  the 
case  of  synchronous  links.  The  data  portion  is  transmitted  next, 
encoded  as  described  below,  followed  by  the  two-octet  sequence 
DLE-ETX.  No  checksum  is  transmitted  or  ejqpected.  If  it  is 
necessary  for  any  reason  to  transmit  time- fill  other  than  in  the 
data  portion,  the  DEL  (all  ones)  is  used. 

2.  Within  the  data  portion  of  the  frame  the  transmit  buffer  is 
scanned  for  a  DLF..  Each  DLE  found  causes  the  sequence  DLE-DLE  to 
be  transmitted.  If  it  Is  necessary  for  some  reason  for  the 
transmitter  to  insert  time- fill  within  the  data  portion,  the 
sequence  DLE -DEL  is  used. 

3.  While  scanning  the  data  stream  within  the  data  portion  of  the 
frame  the  sequence  DLE-DLE  is  found,  a  single  DLE  is  inserted  in 
the  receive  buffer.  If  the  sequence  DLE-ETX  is  found,  the  buffer 
is  passed  on  for  processing.  The  sequence  DLE-DEL  is  discarded. 

Any  other  two-octet  sequence  beginning  wj.th  DLE  and  ending  with 
other  than  DLE,  ETX  or  DEL  is  considered  a  protocol  error 

(see  note  below)  . 

Note:  In  the  case  of  synchronous  links  using  program- interrupt 
Interfaces  such  as  the  DPVll,  for  example,  a  slightly  modified 
protocol  is  suggested  when  both  ends  of  the  link  concur.  These 
interfaces  typically  provide  a  parameter  register  which  can  be  loaded 
with  a  code  used  both  to  detect  the  receiver  synchronizing  pattern  and 
for  time- fill  when  the  transmit  buffer  register  cannot  be  serviced  in 
time  for  the  next  character. 

The  parameter  register  must  be  loaded  with  the  SYN  code  for  this 
protocol  to  work  properly.  However,  should  it  be  necessary  to 
transmit  time- fill,  a  single  SYN  will  be  transmitted,  rather  than  the 
DLE-DEL  sequence  sp€K:ified.  Disruptions  due  to  these  events  can  be 
minimized  by  use  of  the  following  rules: 
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1.  If  the  transmitter  senses  a  time- fill  condition  (usually  by  a 
control  bit  assigned  for  this  purpose)  between  frames  or 
immediately  following  transmission  of  a  DLE,  the  condition  is  ignored. 

2.  If  the  transmitter  senses  a  time- fill  condition  at  other  times  it  sends 
the  sequence  DLE-CAN. 

3.  If  the  receiver  finds  a  SYN  either  between  frames  or  immediately 
followoing  DLE,  the  SYN  is  discarded  without  affecting  sequence 
decoding . 

4.  If  the  receiver  finds  the  sequence  DLE-CAN  in  the  data  portion,  it 
discards  the  sequence  and  the  immediately  preceding  octet. 

These  rules  will  work  in  cases  where  a  single  SYN  has  been 
inserted  by  the  transmitter  and  even  when  a  SYN  has  been  inserted  in 
the  DLE-CAN  sequence.  If  an  overrun  (lost  data)  condition  is  sensed 
at  the  receiver,  the  appropriate  action  is  to  return  to  the 
initial -synchronization  state.  This  should  also  be  the  action  if  any 
code  other  than  STX  is  found  following  the  initial  DLE.  or  if  any 
code  other  than  DLE,  ETX,  DEL  or  CAN  is  found  following  a  DLE  in  the 
data  portion. 

A. 2.  Serial  Links  Using  DDCMP  Devices 

Following  is  a  description  of  the  frame  format  used  on  DEC  DDCMP  links 
with  DMA  interfaces  such  as  the  DEC  DMVll  and  DMRll.  These  interfaces 
inplement  the  DEC  DDCMP  protocol,  which  includes  error  detection  and 
retransmission  cap^ilities.  The  DDC^C>  frame  format  is  as  follows: 

+ - 4. - +  - + - + - + - 4. - 4. - 4. - 4 

I  SYN  SYN  SOH  |Count|Flag  |Resp  |  Seq  |  Adr  |  CRCl  |  Data  |  CRC2  | 

4. - 4. - 4. - 4.  —  ---4 - 4. - 4, - 4. - 4. - 4 

bits  24  14  2  8  8  8  16  ...  16 

With  respect  to  this  diagram,  each  octet  is  transmitted  starting  from  the 
leftmost  octet,  with  the  bits  of  each  octet  transmitted  low-order  bit  first 
The  contents  of  all  fields  except  the  "Data"  field  are  managcxl  by  the 
interface.  The  Internet  datagram  is  placed  in  this  field  as -is,  with  no 
character  or  bit  stuffing  (the  extent  of  this  field  is  indicated  by  the 
interface  in  the  "Count’'  field. 

A. 3.  Seria  l  Links  Using  HDLC  Devices 

Following  is  a  description  of  the  frame  format  used  on  HDLC  links  with 
program- interrupt  interfaces  such  as  the  DEC  DPVll. 

4 - 4 - 4 - 4 - .4 - 4 - 4 

I  Flag  I  Addr  {  Ctrl  |  Data  |  CRC  |  Flag  | 

4 - 4 - 4 - + - 4 - 4 - 4 

coding  01111110  00000000  00000000  xxxxxxxx  cccccccc  01111110 
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With  respect  to  this  diagram,  each  octet  is  transmitted  starting  from 
the  leftmost  octet,  with  the  bits  of  each  octet  transmitted  low- order 
bit  first.  The  code  xxxxxxxx  represents  the  data  portion  and  cccccccc 
represents  the  checksum.  The  bits  between  the  "Flag"  fields  are 
encoded  with  a  bit-stuffing  convention  in  which  a  zero  bit  is  stuffed 
following  a  string  of  five  one  bits.  The  "Addr"  and  "Ctrl"  fields  are 
not  used  and  the  checksum  is  ignored.  The  Internet  datagram  is  placed 
in  the  "Data"  field,  which  must  be  a  multiple  of  ei^t  bits  in  length. 

A. 4.  ARPANET  1822  Links  Using  Local  or  Distant  Host  Interfaces 

Following  is  a  description  of  the  frame  format  used  with  ARPANET 
1822  Local  or  Distant  Host  interfaces.  These  interfaces  can  be  used 
to  connect  a  DCN  host  to  an  ARPANET  IMP,  Gateway  or  Port  Expander  or 
to  connect  two  DCN  hosts  together.  When  used  to  connect  a  DCN  host  to 
an  ARPANET  IMP,  Gateway  or  Port  Ejqpander,  a  96 -bit  1822  leader  is 
prepended  ahead  of  the  Internet  datagram.  The  coding  of  this  leader 
is  as  described  in  BBN  Report  1822.  When  used  to  connect  two  DCN 
hosts  together,  no  leader  is  used  and  the  frame  contains  only  the 
Internet  datagram. 

A.  5.  ARPANET  1822  Links  Using  HDH  Interfaces 

Following  is  a  description  of  the  frame  format  used  with  ARPANET 
1822  HDH  Interfaces.  These  Interfaces  can  be  used  to  connect  a  DCN 
host  to  an  ARPANET  IMP  or  Gateway  or  to  connect  two  DCN  hosts 
together.  In  either  case,  the  frame  format  is  as  described  in 
^pendix  J  of  BBN  Report  1822. 

A. 6.  X.25  LAPB  Links  Using  RSPE  Interfaces 

Following  is  a  description  of  the  frame  format  used  on  X.25  LAPB 
links  with  the  Royal  Signals  and  Radar  Establishment  interfaces. 

These  interfaces  in^^lement  the  X.25  Link  Access  Protocol  -  Balanced 
(LAPB),  also  known  as  the  frame- level  protocol,  using  a  frame  format 
similar  to  that  described  under  A. 3  above.  Internet  datagrams  are 
placed  in  the  data  portion  of  I  frames  and  encoded  with  the 
bit-stuffing  procedure  described  in  A. 3.  There  is  no  packet- level 
format  used  with  these  Interfaces. 

A. 7.  Ethernet  Links 

Following  is  a  description  of  the  frame  format  used  on  Ethernet  links. 

4 - 4 - ^ - + - + - ^ 

I  Dest  Addr  |  Srce  Addr  |  Type  |  Data  |  CRC  j 

•f - - - ▼ - - - - - 4 - 

bits  48  48  16  ...  32 

With  respect  to  this  diagram,  each  field  is  transmitted  starting  from 
the  leftmost  field,  with  the  bits  of  each  field  transmitted  low-order 
bit  first.  The  "Dest  Addr"  and  "Srce  Addr"  contain  48-bit  Ethernet 
addresses,  while  the  "Type"  field  contains  the  assigned  value  for  I? 
datagrams  (0800  hex)  or  for 
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ARP  datagrams  {0806  hex)  .  The  Internet  datagram  is  placed  in  the 
"Data”  field  end  followed  by  the  32-bit  checksum.  The  Address 
Resolution  Pi  c toco  1  (ARP)  is  used  to  establish  the  mapping  between 
Ethernet  address  and  Internet  addresses. 
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TWO  METHODS  FOR  THE  TRANSMISSION  OF  IP  DATAGRAMS  OVER 
IEEE  802.3  NETWORKS 


Status  of  this  Memo 

Ihis  memo  describes  two  methods  of  encapsulating  Internet 
Protocol  (IP)  [1]  datagrams  on  an  IEEE  802.3  network  [2].  This  RFC 
suggests  a  proposed  protocol  for  the  ARPA- Internet  community,  and 
requests  discussion  and  suggestions  for  inprovements .  Distribution 
of  this  memo  is  unlimited. 

Introduction 

The  IEEE  802  project  has  defined  a  family  of  standards  for  Local  Area 
Networks  (LANs)  that  deals  with  the  Physical  and  Data  Link  Layers  as 
defined  by  the  ISO  Open  System  Interconnection  Reference  Model 
(ISO/OSI) .  Several  Physical  Layer  standards  (802.3,  802.4,  and 
802.5)  [2,  3,  4]  and  one  Data  Link  Layer  Standard  (802.2)  [5]  have 
been  defined.  The  IEEE  Physical  Layer  standards  sp>ecify  the  ISO/OSI 
Physical  Layer  and  the  Media  Access  Control  Sublayer  of  the  ISO/OSI 
Data  Link  Layer.  The  802.2  Data  Link  Layer  standard  specifies  the 
Logical  Link  Control  Sublayer  of  the  ISO/OSI  Data  Link  Layer. 

The  802.3  standard  is  based  on  the  Ethernet  Version  2.0  standard  [6]  . 
Hie  Ethernet  Physical  Layer  and  the  802.3  Physical  Layer  are 
compatible  for  all  practical  purposes  however,  the  Ethernet  Data  Link 
Layer  and  the  802.3/802.2  Data  Link  Layer  are  incompatible. 

There  are  many  existing  Ethernet  network  installations  that  transmit 
IP  datagrams  using  the  Ethernet  compatible  standard  described  in  [7]  . 
IEEE  802.3  Physical  Layer  conpatible  connections  can  be  added  to 
these  networks  using  an  an  Ethernet  Data  Link  Layer  compatible  method 
for  transmitting  IP  datagrams  without  violating  the  802.3  standard. 
Alternatively,  an  802.2/802.3  Data  Link  Layer  compatible  method  for 
transmitting  IP  datagrams  can  be  used. 

Ethernet  Compatible  Method 

IEEE  802.3  networks  must  use  48-bit  physical  addresses  and  10 
megabit/second  bandwidth  in  order  to  be  Ethernet  conpatible. 

Tlie  IEEE  802.3  packet  header  is  identical  to  Ethernet  packet  header 
except  for  the  meaning  assigned  to  one  of  the  fields  in  the  header. 

In  an  Ethernet  packet  header  this  field  is  used  as  a  protocol  type 
field  and  in  an  802.3  packet  header  the  field  is  used  as  a  lengt±i 
field.  ‘Ihe  maximum  allowed  length  field  value  on  a  10  megabit /second 
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802.3  network  is  1500.  The  802.3  standard  states  that  packets  with  a 
length  field  greater  than  the  maximum  allowed  length  field  may  be 
ignored,  discarded,  or  used  in  a  private  manner.  Therefore,  the 
length  field  can  be  used  in  a  private  manner  as  a  protocol  type  field 
as  long  as  the  protocol  types  being  used  are  greater  than  1500.  The 
protocol  type  for  IP,  ARP  and  trailer  encapsulation  are  all  greater 
than  1500.  Using  this  technique,  the  method  for  transmitting  IP 
datagrams  on  Ethernet  networks  described  in  [7]  can  be  used  to 
transmit  IP  datagrams  on  IEEE  802-3  networks  in  an  Ethernet 
compatitle  manner. 

IEEE  802.2/802.3  Compatible  Method 
Frame  Format 

IP  datagrams  are  transmitted  in  standard  802.2/802.3  LLC  Type  1 
Unnumbered  Information  format  with  the  DSAP  and  SSAP  fields  of  the 
802.2  header  set  to  96,  the  IEEE  assigned  global  SAP  value  for 
IP  [8]  -  The  data  field  contains  the  IP  header  followed 
immediately  by  the  IP  data. 

IEEE  802.3  packets  have  minimum  size  restrictions  based  on  network 
bandwidth.  When  necessary,  the  data  field  should  be  padded  (with 
octets  of  zero)  to  meet  the  802.3  minimum  frame  size  requirements. 
This  padding  is  not  part  of  the  IP  packet  and  is  not  included  in 
the  total  length  field  of  the  IP  header. 

IEEE  802.3  packet::  have  maximum  size  restrictions  based  on  the 
network  bandwidth.  Implementations  are  encouraged  to  support 
full-length  packets. 

Gateway  implementations  MUST  be  prepared  to  accept  full-length 
packets  and  fragment  them  when  necessary. 

Host  inplementavions  should  be  prepared  to  accept  full-length 
packets,  however  hosts  MUST  NOT  send  datagrams  longer  than  576 
octets  unless  th*r/  have  explicit  knowledge  that  the  destination 
is  prepared  to  accept  them.  A  host  may  communicate  its  size 
preference  in  TCP  based  applications  via  the  TCP  Maximum 
Segment  Size  optii  n  [9]  . 

Note:  Datagrams  on  802-3  networks  may  be  longer  than  the  general 
Internet  default  maximum  packet  size  of  576  octets.  Hosts 
connected  to  an  802.3  network  should  keep  this  in  mind  when 
sending  datagrams  to  hosts  not  on  the  same  802.3  network.  It  may 
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be  appropriate  to  send  smaller  datagrams  to  avoid  unnecessary 
fragmentation  at  intermediate  gateways.  Please  see  [9]  for 
further  information  on  this  point. 

Address  Mappings 

The  mapping  of  32 -bit  Internet  addresses  to  16 -bit  or  48 -bit  802.3 
addresses  can  be  done  in  several  ways.  A  static  table  could  be 
used,  or  a  dynamic  discovery  procedure  could  be  used. 

Static  Table 

Each  host  could  be  provided  with  a  table  of  all  other  hosts  on 
the  local  network  with  both  their  CO 2. 3  and  Internet  addresses. 

Dynamic  Discovery 

Mappings  between  32 -bit  Internet  addresses  and  802.3  addresses 
could  be  acconplished  through  a  protocol  similar  to  the 
Ethernet  Address  Resolution  Protocol  (ARP)  [10] .  Internet 
addresses  are  assigned  arbitrarily  on  some  Internet  networks. 
Each  host's  implementation  must  know  its  own  Internet  address 
and  respond  to  802.3  Address  Resolution  packets  appropriately. 
It  should  also  use  ARP  to  translate  Internet  addresses  to  802.3 
addresses  when  needed. 

Broadcast  Address 

Ihe  broadcast  Internet  address  (the  address  on  that  network 
with  a  host  part  of  all  binary  ones)  should  be  mapped  to  the 
broadcast  802.3  address  (of  all  binary  ones) . 

Ihe  use  of  the  ARP  dynamic  discovery  procedure  is  strongly 
recommended . 

Trailer  Formats 

Some  versions  of  Unix  4.2bsd  Uiie  a  different  encapsulation  method 
in  order  to  get  better  network  performance  with  the  VAX  virtual 
memory  architecture.  Consenting  systems  on  the  same  802.3  network 
may  use  this  format  between  themselves.  Details  of  the  trailer 
encapsulation  method  may  be  found  in  [11]  . 
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Byte  Order 

As  described  in  Af^ndix  B  of  the  Internet  Protocol  specification 

[1],  the  IP  datagram  is  transmitted  over  802.2/802.3  networks  as  a 
series  of  8-bit  bytes. 

Conclusion 

Ihe  two  encapsulation  methods  presented  can  be  mixed  on  the  same 
local  area  network;  however,  this  would  partition  the  network  into 
two  inconpatible  subnetworks.  One  host  on  a  network  could  support 
both  methods  and  act  as  a  gateway  between  the  two  subnetworks; 
however,  this  would  introduce  a  significant  performance  penalty  and 
should  be  avoided. 

The  IEEE  802.2/802.3  conpatible  encapsulation  method  is  preferable  to 
the  Ethernet  compatible  method  because  the  IEEE  802.2  and  IEEE  802.3 
standards  have  been  accepted  both  nationally  and  internationally  and 
because  the  same  encapsulation  method  could  be  used  on  other  IEEE  802 
Physical  Layer  implementations.  However,  there  are  many  existing 
installations  that  are  using  IP  on  Ethernet  and  a  controlled 
transition  from  Ethernet  to  IEEE  802.2/802.3  is  necessary. 

To  this  end,  all  new  inplementations  should  allow  for  a  static  choice 
of  encapsulation  methods  and  all  existing  inplementations  should  be 
modified  to  provide  this  static  choice  as  well.  During  the 
transition,  all  hosts  on  the  same  network  would  use  the  Ethernet 
compatible  method.  After  802.2/802.3  support  has  been  added  to  all 
existing  implementations,  the  IEEE  802.2/802.3  method  would  be  used 
and  the  transition  would  be  complete. 
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A  Standard  for  the  Transmission  of  IP  Datagrams  over  Ethernet  Networks 


Status  of  this  Memo 

This  RFC  specifies  a  standard  method  of  encapsulating  Internet 
Protocol  (IP)  [1]  datagrams  on  an  Ethernet  [2] .  This  RFC  specifies  a 
standard  protocol  for  the  ARPA- Internet  coosunlty. 

Introduction 

This  memo  applies  to  the  Ethernet  (10*megablt/second,  48-blt 
addresses)  .  The  procedure  for  transmission  of  IP  datagrams  on  the 
Experimental  Ethernet  (3'm8gablt/second,  8'blt  addresses)  Is 
described  In  [3] . 

Frame  Format 

IP  datagrams  are  transmitted  In  standard  Ethernet  frames.  The  type 
field  of  the  Ethernet  frame  must  contain  the  value  hexadecimal  0800. 
The  data  field  contains  the  IP  header  followed  Inaedlately  by  the  IP 
data. 

The  minimum  length  of  the  data  field  of  a  packet  sent  over  an 
Ethernet  Is  46  octets.  If  necessary,  the  data  field  should  be  padded 
(with  octets  of  zero)  to  meet  the  Ethernet  minimum  frame  size.  This 
{Adding  Is  not  part  of  the  IP  packet  and  Is  not  Included  in  the  total 
length  field  of  the  IP  header. 

The  minimum  length  of  the  data  field  of  a  packet  sent  over  an 
Ethernet  Is  1500  octets,  thus  the  maximum  length  of  an  IP  datagram 
sent  over  an  Ethernet  Is  1500  octets.  Inplementatlons  are  encouraged 
to  support  full-length  packets.  Catoway  Inplementatlons  MUST  be 
prepared  to  accept  full-length  pacl.ets  and  fragment  them  If 
necessary.  If  a  system  cannot  receive  full-length  packets.  It  should 
take  steps  to  discourage  others  from  sending  them,  such  as  using  the 
TCP  Maximum  Segaent  Size  option  [4]  . 

Note:  Datagrams  on  the  Ethernet  may  be  longer  than  the  general 
Internet  default  maximum  packet  size  of  576  octets.  Hosts  connected 
to  an  Ethernet  should  keep  this  In  adnd  when  sending  datagrams  to 
hosts  not  on  the  same  Ethernet.  It  may  be  appropriate  to  send 
smaller  datagrams  to  avoid  unnecessary  fragmentation  at  Intermediate 
gateways.  Please  see  [4]  for  further  Information  on  this  point. 
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Address  Mappings 

The  mapping  of  32 -bit  Internet  addresses  to  48 -bit  Ethernet  addresses 
can  be  done  several  ways.  A  static  table  could  be  used,  or  a  dynamic 
discovery  procedure  could  be  used. 

Static  Table 

Each  host  could  be  provided  with  a  table  of  all  other  hosts  on  the 
local  network  with  both  their  Ethernet  and  Internet  addresses. 

Dynamic  Discovery 

Mappings  between  32 -bit  Internet  addresses  and  48 -bit  Ethernet 
addresses  could  be  accomplished  throu^  the  Address  Resolution 
Protocol  (ARP)  [5] .  Internet  addresses  are  assigned  arbitrarily 
on  some  Internet  network.  Each  host’s  inplementation  must  know 
its  own  Internet  address  and  respond  to  Ethernet  Address 
Resolution  packets  appropriately.  It  should  also  use  ARP  to 
translate  Internet  addresses  to  Ethernet  addresses  when  needed. 

Broadcast  Address 

The  broadcast  Internet  address  (the  address  on  that  network  with  a 
host  part  of  all  binary  ones)  should  be  mapped  to  the  broadcast 
Ethernet  address  (of  all  binary  ones,  FF-FF-FF-FF-FF-FF  hex) . 

The  use  of  the  ARP  dynamic  discovery  procedure  is  strongly 
reconmended . 

Trailer  Fon?^ts 

Some  versions  of  Unix  4.2bsd  use  a  different  encapsulation  method  in 
order  to  get  better  network  performance  with  the  VAX  virtual  memory 
architecture.  Consenting  systems  on  the  same  Ethernet  may  use  this 
format  between  themselves. 

No  host  is  required  to  inplement  it,  and  no  datagrams  in  this  format 
should  be  sent  to  any  host  unless  the  sender  has  positive  knowledge 
that  the  recipient  will  be  able  to  interpret  them.  Details  of  the 
trailer  encapsulation  may  be  found  in  [6] . 

(Note:  At  the  present  time  Unix  4.2bsd  will  either  always  use 
trailers  or  never  use  them  (per  interface) ,  depending  on  a  boot- time 
option.  'Ihls  is  expected  to  be  changed  in  the  future.  Unix  4.2bsd 
also  uses  a  non-standard  Internet  broadcast  address  with  a  host  part 
of  all  zeroes,  this  may  also  be  changed  in  the  future.) 
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Byte  Order 

As  described  In  Appendix  B  of  tfae  Internet  yrotaco^ 
specification  [1] ,  the  IP  datagrsB  is  trarsaitaaid  wme  Siaaeraet 
as  a  series  of  8-bit  bytes. 
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A  Standard  for  the  TIransBission  of  IP  Datagrams 
wer  Esg^erisental  Ethernet  Hetworks 


Statxs  of  this  Memo 

This  SEC  specifies  a  standard  method  of  encapsulating  Internet 
Protocol  (IP)  [1]  datagrams  on  an  Esqserlmental  Ethernet  [2]  .  This 
SEl  specifies  a  standard  protocol  for  the  ARPA  Internet  ccsssunity. 

Introduction 


This  memo  applies  to  the  Esg^erlmental  Ethernet  (J-megabit/second, 
8-bit  addresses) .  The  procedure  for  transmission  of  IP  datagrams  on 
the  Ethernet  (IC-megablt/second.  48-bit  addresses)  is  described  in 


IP  data^^ams  are  transmitted  in  standard  Experimental  Ethernet 
frames.  The  typB  field  of  the  Ethernet  frame  must  contain  the  value 
513  (1001  octal) .  The  data  field  contains  the  IP  header  followed 
If  ni  iTf  iy  Of  the  iP  data. 

If  necessary^  the  data  field  should  be  padded  to  meet  the 
Csqperlmental  Ethernet  minImiM  fr^me  size.  This  padding  Is  not  part 
of  the  IP  packet  and  Is  not  Included  in  the  total  length  field  of  the 
IP  header. 


The  warrimim  length  of  an  I?  datagram  sent  over  an  £3g)erimental 

Is  1536  octets.  Is^leme--.taticn5  are  encouraged  to  support 
fhll-length  packets.  Gateway  i^lementatlons  MUST  be  prq>ared  to 
accept  full-length  packets  and  fra^ent  them  if  necessary.  If  a 
system  canrot  receive  full-length  packets,  it  ^lould  take  steps  to 
discourage  others  from  sending  them,  sucdi  as  using  the  TCP  Maximum 
SegKnt  Size  option  [4] . 

iiote:  Datagrams  on  the  Ethernet  may  he  longer  than  the  general 
Internet  default  mavlmim  paedeet  size  of  576  octets.  Hosts  connected 
to  Ethernet  ^xxild  keep  this  in  mind  idien  sending  datagrams  to 
hosts  not  on  the  same  Ethernet.  It  may  be  appropriate  to  send 
smaller  datagrams  to  avoid  unnecessary  fra^Kntation  at  intermediate 
gateways.  Please  see  [4]  fer  further  information  on  this  point. 


1  T 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1985 


RFC  895 


April  1984 


Address  Mappings 

The  mapping  between  32 -bit  Internet  addresses  to  8-bit  Experimental 
Ethernet  addresses  can  be  done  several  ways. 

The  easiest  thing  to  do  is  to  use  the  last  ei^t  bits  of  host  number 
part  of  the  Internet  address  as  the  host's  address  on  the 
E^gjerlmental  Ethernet.  This  is  the  recommended  approach. 

Broadcast  Address 

The  broadcast  Internet  address  (the  address  on  that  network  with  a 
host  part  of  all  binary  ones)  ^ould  be  mapped  to  the  broadcast 
Eaqperimental  Ethernet  address  (address  zero)  . 

Trailer  Formats 

Some  versions  of  Unix  4.2bsd  use  a  different  encapsulation  method  in 
order  to  get  better  network  performance  with  the  VAX  virtual  memory 
architecture.  Consenting  systems  on  the  same  Ethernet  may  use  this 
format  between  themselves. 

No  host  is  required  to  implement  it,  and  no  datagrams  in  this  format 
should  be  sent  to  any  host  unless  the  sender  has  positive  knowledge 
that  the  recipient  will  be  able  to  interpret  them.  Details  of  the 
trailer  encapsulation  may  be  found  in  [6]  . 

(Note;  At  the  present  time  Unix  4.2bsd  will  either  always  use 
trailers  or  never  use  them  (per  Interface) ,  depending  on  a  boot -time 
option.  This  is  expected  to  be  changed  in  the  future.  Unix  4.2bsd 
also  uses  a  non-standard  Internet  broadcast  address  with  a  host  part 
of  all  zeroes,  this  will  also  be  changed  in  the  future.) 

Byte  Order 

As  described  in  ^pendix  B  of  the  Internet  Protocol 
specification  [1]  ,  the  IP  datagram  is  transmitted  over  the  Ethernet 
as  a  series  of  8-bit  bytes. 
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An  Ethernet  Address  Resolution  Protocol 
—  or  — 

Converting  Network  Protocol  Addresses 
to  48. bit  Ethernet  Address 
for  Transmission  on 
Ethernet  Hardware 


Abstract 

The  inplementation  of  protocol  P  on  a  sending  host  S  decides, 
throu^  protocol  P's  routing  mechanism;  that  it  wants  to  transmit 
to  a  target  host  T  located  some  place  on  a  connected  piece  of 
10Mbit  Ethernet  cable.  To  actually  transmit  the  Ethernet  packet 
a  48. bit  Ethernet  address  must  be  generated.  The  addresses  of 
hosts  within  protocol  P  are  not  always  coinpatible  with  the 
corresponding  Ethernet  address  (being  different  lengths  or 
values) .  Presented  here  is  a  protocol  that  allows  dynamic 
distribution  of  the  information  needed  to  build  tables  to 
translate  an  address  A  in  protocol  P's  address  space  into  a 
48. bit  Ethernet  address. 

Generalizations  have  been  made  which  allow  the  protocol  to  be 
used  for  non- 10Mbit  Ethernet  hardware.  Some  packet  radio 
networks  are  exasples  of  such  hardware. 


The  protocol  proposed  here  is  the  result  of  a  great  deal  of 
discussion  with  several  other  people,  most  notably  J .  Noel 
Chiappa,  Yogen  Dalai,  and  James  E.  Kulp,  and  helpful  comments 
from  David  Moon. 


[The  purpose  of  this  RFC  is  to  present  a  method  of  Converting 
Protocol  Addresses  (e.g.,  IP  addresses)  to  Local  Network 
Addresses  (e.g.,  Ethernet  addresses) .  This  is  a  issue  of  general 
concern  in  the  ARPA  Internet  comnpjnity  at  this  time.  The 
method  proposed  here  is  presented  for  your  consideration  and 
comment.  This  is  not  the  specification  of  a  Internet  Standard.] 


David  C.  Plummer 
(DCP@MIT-MC) 
November  1982 
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Notes: 


Hiis  protocol  was  originally  designed  for  the  DEC/Intel/Xerox 
10Mbit  Ethernet.  It  has  been  generalized  to  allow  it  to  be  used 
for  other  types  of  networks.  Much  of  the  discussion  will  be 
directed  toward  the  10Mbit  Ethernet.  Generalizations,  vdiere 
applicable,  will  follow  the  Ethernet-specific  discussion. 

DOD  Internet  Protocol  will  be  referred  to  as  Internet. 

Numbers  here  are  in  the  Ethernet  standard,  which  is  hi^  byte 
first.  This  is  the  opposite  of  the  byte  addressing  of  machines 
such  as  PDP-lls  and  VAXes.  Therefore,  special  care  must  be  taken 
with  the  qpcode  field  (ar$op)  described  below. 

An  agreed  upon  authority  is  needed  to  manage  hardware  name  space 
values  (see  below) .  Until  an  official  authority  exists,  requests 
should  be  submitted  to 

David  C.  Plummer 
Symbolics,  Inc. 

243  Vassar  Street 
Cambridge,  Massachusetts  02139 
Alternatively,  network  mail  can  be  sent  to  DCP®MIT-MC. 

The  Problem: 


The  world  is  a  jungle  in  general,  and  the  networking  game 
contributes  many  animals.  At  nearly  every  layer  of  a  network 
architecture  there  are  several  potential  protocols  that  could  be 
used.  For  example,  at  a  hi^  level,  there  is  TELNET  and  SUPDUP 
for  remote  login..  Somewhere  below  that  there  is  a  ratable  byte 
stream  protocol,  which  mi^t  be  CHAOS  protocol,  DOD  TCP,  Xerox 
BSP  or  DECnet.  Even  closer  to  the  hardware  is  the  logical 
transport  layer,  which  might  be  CHAOS,  DOD  Internet,  X^rox  PUP, 
or  DECnet.  The  10Mbit  Ethernet  allows  all  of  these  protocols 
(and  more)  to  coexist  on  a  single  cable  by  means  of  a  type  field 
in  the  Ethernet  packet  header.  However,  the  10Mbit  Ethernet 
requires  48. bit  addresses  on  the  physical  cable,  yet  most 
protocol  addresses  are  not  48. bits  long,  nor  do  they  necessarily 
have  any  relationship  to  the  48. bit  Ethernet  address  of  the 
hardware.  For  example,  CHAOS  addresses  are  16 .bits,  DCD  Internet 
addresses  are  32 .bits,  and  Xerox  PUP  addresses  are  8. bits.  A 
protocol  is  needed  to  dynamically  distribute  the  correspondences 
between  a  <protocol,  address>  pair  and  a  48. bit  Ethernet  address. 
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Motivation: 


Use  of  the  10Mbit  Ethernet  is  increasing  as  more  manufacturers 
supply  Interfaces  that  conform  to  the  specification  published  by 
DEC,  Intel  and  Xerox.  With  this  increasing  availability,  more 
and  more  software  is  being  written  for  these  interfaces.  There 
are  two  alternatives:  (1)  Every  Implementor  invents  his/her  own 
method  to  do  some  form  of  address  resolution,  or  (2)  every 
implementor  uses  a  standard  so  that  his/her  code  can  be 
distributed  to  other  s^-stems  without  need  for  modification.  This 
proposal  attempts  to  set  the  standard. 

Definitions: 


Define  the  following  for  referring  to  the  values  put  in  the  TYPE 
field  of  the  Ethernet  packet  header: 
ether_type$XEROX_PUP . 
ether_type$DOD_INTERNET, 
ether_type$CHAOS , 
and  a  new  one: 

ether_type$ADDRESS JRESOLUTION . 

Also  define  the  following  values  (to  be  discussed  later)  : 

ares_op$REQUEST  (=  1,  high  byte  transmitted  first)  and 
ares_op$REPLY  (=  2) , 

and 

ares_hrd$Ethemet  (=  1)  . 

Packet  format: 


To  communicate  mappings  from  <protocol,  address>  pairs  to  48. bit 
Ethernet  addresses,  a  packet  format  that  embodies  the  Address 
Resolution  protocol  is  needed.  The  format  of  the  packet  loIIows, 

Ethernet  transmission  layer  (not  necessarily  accessible  to 
the  user) : 

48 .bit:  Ethernet  address  of  destination 
48. bit:  Ethernet  address  of  sender 

16. bit:  Protocol  type  =  ether_type$ADDRESS_RESOLUTION 
Ethernet  packet  data: 

16 .bit:  (ar$hrd)  Hardware  address  space  (e.g.,  Ethernet, 
Packet  Radio  Net.) 

16 .bit:  (ar$pro)  Protocol  address  space.  For  Ethernet 
hardware,  this  is  from  the  set  of  type 
fields  ether_typ$<protocol> . 

8. bit:  (ar$hln)  byte  length  of  each  hardware  address 
8. bit:  (ar$pln)  byte  length  of  each  protocol  address 
16. bit:  (ar$op)  opcode  (ares_op$PXQUEST  |  ares_op$REPLY) 
nbytes:  (ar$sha)  l^rdware  address  of  sender  of  this 
packet,  n  from  the  ar$hln  field, 
mbytes:  (ar$spa)  Protocol  address  of  sender  of  this 
packet,  m  from  the  ar$pln  field, 
nbytes:  (ar$tha)  Hardware  address  of  target  of  this 
packet  (if  known) . 

mbytes:  (ar$tpa)  Protocol  address  of  target. 
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Packet  Generation: 


As  a  packet  is  sent  down  throu^  the  network  layers,  routing 
determines  the  protocol  address  of  the  next  hop  for  the  packet 
and  on  which  piece  of  hardware  it  expects  to  find  the  station 
with  the  inanediate  target  protocol  address.  In  the  case  of  the 
10Mbit  Ethernet,  address  resolution  is  needed  and  some  lower 
layer  (probably  the  hardware  driver)  must  consult  the  Address 
Resolution  module  (perhaps  inplemented  in  the  Ethernet  support 
module)  to  convert  the  <protocol  type,  target  protocol  address> 
pair  to  a  48 .bit  Ethernet  address.  The  Adless  Resolution  module 
tries  to  find  this  pair  in  a  table.  If  it  finds  the  pair,  it 
gives  the  corresponding  48. bit  Ethernet  address  back  to  the 
caller  (hardware  driver)  which  then  transmits  the  packet.  If  it 
does  not,  it  probably  informs  the  caller  that  it  is  throwing  the 
packet  away  (on  the  assumption  the  packet  will  be  retransmitted 
by  a  higher  network  layer) ,  and  generates  an  Ethernet  packet  with 
a  type  field  of  ether_type$ADDRESS,JlESOLUTION.  The  Address 
Resolution  module  then  sets  the  ar$hrd  field  to  < 

aresJird$Ethemet,  ar$pro  to  the  protocol  type  that  is  being 
resolved,  ar$hln  to  6  (the  number  of  bytes  in  a  48. bit  Ethernet 
address) ,  ar$pln  to  the  length  of  an  address  in  that  protocol, 
ardop  to  ares_op$REQUEST,  ar$sha  with  the  48. bit  ethemet  address 
of  itself,  ar$spa  with  the  protocol  address  of  itself,  and  ar$tpa 
with  the  protocol  address  of  the  machine  that  is  trying  to  be 
accessed.  It  does  not  set  ar$tha  to  anything  in  particular, 
because  it  is  this  value  that  it  is  trying  to  determine.  It 
could  set  ar$tha  to  the  broadcast  address  for  the  hardware  (all 
ones  in  the  case  of  the  10Mbit  Ethemet)  if  that  makes  it 
convenient  for  some  aspect  of  the  implementation.  It  then  causes 
this  packet  to  be  broadcast  to  all  stations  on  the  Ethemet  cable 
originally  determined  by  the  routing  mechanism. 
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Packet  Reception: 


When  an  address  resolution  packet  is  received,  the  receiving 
Ethernet  module  gives  the  packet  to  the  Address  Resolution  module 
vhlch  goes  throu^  an  algorithm  similar  to  the  following. 

Negative  conditionals  in^cate  an  end  of  processing  and  a 
discarding  of  the  packet. 

?Do  I  have  the  hardware  type  in  ar$hrd? 

Yes :  (almost  definitely) 

[optionally  check  the  hardware  length  ar$hln] 

?Do  I  speak  the  protocol  in  ar$pro? 

Yes: 

[optionally  chock  the  protocol  length  ar$pln] 

Mergo^flag  :=  false 

If  the  pair  <protocol  type,  sender  protocol  address>  is 
already  in  my  translation  table,  update  the  sender 
hardware  address  field  of  the  entry  with  the  now 
information  in  the  packet  and  set  Merge.flag  to  true. 

?Am  I  the  target  protocol  address? 

Yes: 

If  Merge.flag  is  false,  add  the  triplet  <protocol  type, 
sender  protocol  address,  sender  hardware  address>  to 
the  translation  table. 

?Is  the  opcode  ares_op$REQUEST?  (NOW  look  at  the  opcode!!) 
Yes: 

SW^  hardware  and  protocol  fields,  putting  the  local 

hardware  and  protocol  addresses  in  the  sender  fields. 
Set  the  ar$op  field  to  ares_op$R£PLY 
Send  the  packet  to  the  (new)  target  hardware  address  on 
the  same  hardware  on  ^diich  the  request  was  received. 

Notice  that  the  <protocol  type,  sender  protocol  address,  sender 
hardware  address>  triplet  is  merged  into  the  table  before  the 
opcode  is  looked  at.  Ihis  is  on  the  assuxEption  that  communcation 
is  bidirectional;  if  A  has  some  reason  to  talk  to  B,  then  B  will 
probably  have  some  reason  to  talk  to  A.  Notice  also  that  if  an 
entry  already  exists  for  the  <protocol  type,  sender  protocol 
address>  pair,  then  the  new  hardware  address  supersedes  the  old 
one.  Related  Issues  gives  some  motivation  for  this. 

Generalization:  The  ar$hrd  and  ar$hln  fields  allow  this  protocol 
and  packet  format  to  be  used  for  non*10Mbit  Ethernets.  For  the 
10Mbit  Ethernet  <ar$hrd,  ar$hln>  takes  on  the  value  <1,  6>.  For 
other  hardware  networks,  the  ar$pro  field  may  no  longer 
correspond  to  the  Ethernet  type  field,  but  it  should  be 
associated  with  the  protocol  whose  address  resolution  is  being 
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Why  is  it  done  this  way?? 


Periodic  broadcasting  is  definitely  not  desired.  Imagine  100 
workstations  on  a  single  Ethernet «  each  broadcasting  address 
resolution  information  once  per  10  minutes  (as  one  possible  set 
of  parameters)  .  This  is  one  packet  every  6  seconds.  This  is 
almost  reasonable^  but  what  use  is  it?  The  workstations  aren't 
generally  going  to  be  talking  to  each  other  (and  therefore  have 
100  useless  entries  in  a  table) ;  they  will  be  mainly  talking  to  a 
mainframe,  file  server  or  bridge,  but  only  to  a  small  number  of 
other  workstations  (for  interactive  conversations,  for  exanple)  . 
The  protocol  described  in  this  paper  distributes  information  as 
it  is  needed,  and  only  once  (probably)  per  boot  of  a  machine. 

This  format  does  not  allow  for  more  than  one  resolution  to  be 
done  in  the  same  packet.  This  is  for  simplicity.  If  things  were 
multiplexed  the  packet  format  would  be  considerably  harder  to 
digest,  and  much  of  the  information  could  be  gratuitous.  Think 
of  a  bridge  that  talks  four  protocols  telling  a  workstation  all 
four  protocol  addresses,  three  of  which  the  workstation  will 
probably  never  use. 

This  format  allows  the  packet  buffer  to  be  reused  if  a  reply  is 
generated;  a  reply  has  the  same  length  as  a  request,  and  several 
of  the  fields  are  the  same. 

The  value  of  the  hardware  field  (ar$hrd)  is  taken  from  a  list  for 
this  purpose .  Currently  the  only  defined,  value  is  for  the  lOMblt 
Ethernet  (ares,Jird$Ethemet  =  1)  .  There  has  been  talk  of  using 
this  protocol  for  Packet  Radio  Networks  as  well,  and  this  will 
require  another  value  as  will  other  future  hardware  mediums  that 
wish  to  use  this  protocol. 

For  the  lOMblt  Ethernet,  the  value  in  the  protocol  field  (ar$pro) 
is  taken  from  the  set  ether.type$.  This  is  a  natural  reuse  of 
the  assigned  protocol  types.  Combining  this  with  the  opcode 
(ar$op)  would  effectively  halve  the  number  of  protocols  that  can 
be  resolved  under  this  protocol  and  would  make  a  monitor /debugger 
more  conplex  (see  Network  Monitoring  and  Debugging  below)  .  It  is 
hoped  that  we  will  never  see  32768  protocols,  but  Murphy  made 
some  laws  which  don't  allow  us  to  make  this  assunption. 

In  theory,  the  length  fields  (ar$hln  and  ar$pln)  are  redundant, 
since  the  length  of  a  protocol  address  should  be  determined  by 
the  hardware  type  (found  in  ar$hrd)  and  the  protocol  type  (found 
in  ar^ro)  .  It  is  included  for  optional  consistency  checking, 
and  for  network  monitoring  and  debugging  (see  below)  . 

The  opcode  is  to  determine  if  this  is  a  request  (which  may  cause 
a  reply)  or  a  reply  to  a  previous  request.  16  bits  for  this  is 
overkill,  but  a  flag  (field)  is  needed. 

The  sender  hardware  address  and  sender  protocol  address  are 
absolutely  necessary.  It  is  these  fields  that  get  put  in  a 
translation  table. 
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The  target  protocol  address  is  necessary  in  the  request  form  of 
the  packet  so  that  a  machine  can  determine  whether  or  not  to 
enter  the  sender  information  in  a  table  or  to  send  a  reply.  It 
is  not  necessarily  needed  in  the  reply  form  if  one  assumes  a 
reply  is  only  provoked  by  a  request.  It  is  included  for 
conpieteness,  network  monitoring,  and  to  simplify  the  suggested 
processing  algorithm  described  above  (which  does  not  look  at  the 
opcode  until  AFTER  putting  the  sender  information  in  a  table)  . 

The  target  hardware  address  is  included  for  completeness  and 
network  monitoring.  It  has  no  meaning  in  the  request  form,  since 
it  is  this  number  that  the  machine  is  requesting.  Its  meaning  in 
the  reply  form  is  the  address  of  the  machine  making  the  request. 
In  some  implementations  (which  do  not  get  to  look  at  the  14. byte 
ethemet  header,  for  example)  this  may  save  some  register 
shuffling  or  stack  ^ace  by  sending  this  field  to  the  hardware 
driver  as  the  hardware  destination  address  of  the  packet. 

There  are  no -padding  bytes  between  addresses.  The  packet  data 
^ould  be  viewed  as  a  byte  stream  in  which  only  3  b^e  pairs  are 
defined  to  be  words  (ar$hrd,  ar$pro  and  ar$qp)  which  are  sent 
most  significant  byte  first  (Ethemet/PDP-10  byte  style)  . 
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Network  monitoring  and  debugging: 


The  above  Address  Resolution  protocol  allovis  a  machine  to  gain 
knowledge  about  the  higher  level  protocol  activity  (e.g.,  QIAOS, 
Internet,  PUP,  DECnet)  on  an  Ethernet  cable.  It  can  determine 
which  Ethernet  protocol  type  fields  are  in  use  (by  value)  and  the 
protocol  addresses  within  each  protocol  type.  In  fact,  it  is  not 
necessary  for  the  monitor  to  speak  any  of  the  hlg^r  level 
protocols  involved.  It  goes  something  like  this: 

Nhen  a  monitor  receives  an  Address  Resolution  packet,  it  always 
enters  the  <protocol  type,  sender  protocol  address,  sender 
hardware  addS'ess>  in  a  table.  It  can  determine  the  length  of  the 
hardware  and  protocol  address  from  the  ar$hln  and  ar$pln  fields 
of  the  packet.  If  the  opcode  is  a  REPLY  the  monitor  can  then 
throw  the  packet  away.  If  the  opcode  is  a  REC^JEST  and  the  target 
protocol  address  matches  the  protocol  address  of  tte  monitor,  the 
monitor  sends  a  REPLY  as  it  normally  would.  The  monitor  will 
only  get  one  mapping  this  way,  since  the  REPLY  to  the  REQUEST 
will  bo  sent  directly  to  the  requesting  host.  The  monitor  could 
try  sending  its  own  REQUEST,  but  this  could  get  two  monitors  into 
a  REQUEST  sending  loop,  and  care  must  be  taken. 

Because  the  protocol  and  opcode  are  not  coinbined  into  one  field, 
the  monitor  does  not  need  to  know  ^^ch  request  opcode  is 
associated  with  which  reply  opcode  for  the  same  higher  level 
protocol.  The  length  fields  ^ould  also  give  enou^  information 
to  enable  it  to  "parse”  a  protocol  addresses,  althou^  it  has  no 
knowledge  of  \diat  the  protocol  addresses  mean. 

A  working  t nplementat ion  of  the  Address  Resolution  protocol  can 
also  be  used  to  debug  a  non-working  inplementation .  Presumsbly  a 
hardware  driver  will  successfully  broadcast  a  packet  with  Ethernet 
type  field  of  ether„type$ADDRESS_RESOLUTION.  The  format  of  the 
packet  may  not  be  totally  correct,  beciuse  initial 
implementations  may  have  bugs,  and  table  management  may  be 
slightly  tricky.  Because  requests  are  broadcast  a  monitor  will 
receive  the  packet  and  can  display  it  for  debugging  if  desired. 
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Related  issue: 


It  may  be  desirable  to  have  table  aging  and/or  timeouts.  The 
implementation  of  these  is  outside  the  scope  of  this  protocol. 
Here  is  a  more  detailed  description  (thanks  to  MOON@SCRC(gMIT-MC)  . 

If  a  host  moves,  any  connections  initiated  by  that  host  will 
work,  assuming  its  own  address  resolution  table  is  cleared  when 
it  moves.  However,  connections  initiated  to  it  by  other  hosts 
will  have  no  particular  reason  to  know  to  discard  their  old 
address.  However,  48. bit  Ethernet  addresses  are  supposed  to  be 
unique  and  fixed  for  all  tiiie,  so  they  shouldn‘t  change.  A  host 
could  ’‘move’*  if  a  host  name  (and  address  in  some  other  protocol) 
were  reassigned  to  a  different  physical  piece  of  hardware.  Also, 
as  we  know  from  experience,  there  is  always  the  danger  of 
incorrect  routing  information  accidentally  getting  transmitted 
through  hardware  or  software  error;  it  should  not  be  allowed  to 
persist  forever.  Perhaps  failure  to  initiate  a  connection  should 
inform  the  Address  Resolution  module  to  delete  the  information  on 
the  basis  that  the  host  is  not  reachable,  possibly  because  it  is 
down  or  the  old  translation  is  no  longer  valid.  Or  perhaps 
receiving  of  a  packet  from  a  host  should  reset  a  timeout  in  the 
address  resolution  entry  used  for  transmitting  packets  to  that 
host;  if  no  packets  are  received  from  a  host  for  a  suitable 
length  of  time,  the  address  resolution  entry  is  forgotten.  This 
may  cause  extra  overhead  to  scan  the  table  for  each  incoming 
packet.  Perhaps  a  hash  or  index  can  make  this  faster. 

Iho  suggested  algorithm  for  receiving  address  resolution  packets 
tries  to  lessen  the  time  it  takes  for  recov'ery  if  a  host  does 
movr.  Recall  that  if  the  <protocol  type,  sender  protocol 
address>  is  already  in  the  translation  table,  then  the  sender 
hardware  address  supersedes  the  existing  entry.  Therefore,  on  a 
perfect  Ethernet  where  a  broadcast  REQUEST  reaches  all  stations 
on  the  cable,  each  station  will  be  get  the  new  hardware  address. 

Another  alternative  Is  to  have  a  daemon  perform  the  timeouts. 
After  a  suitable  time,  the  daemon  considers  removing  an  entry. 

It  first  sends  (with  a  small  number  of  retransmissions  if  ne^ed) 
an  address  resolution  packet  with  opcode  REQUEST  directly  to  the 
Ethernet  address  in  the  table.  If  a  REPLY  is  not  seen  in  a  short 
amount  of  time,  the  entry  is  deleted.  The  request  is  sent 
directly  so  as  not  to  bother  every  station  on  the  Ethernet.  Just 
forgetting  entries  will  likely  cause  useful  infor-mation  to  be 
forgotten,  which  must  be  regained. 

Since  hosts  don’t  transmit  information  about  anyone  other  than 
themselves,  rebooting  a  host  will  cause  its  address  mapping  table 
to  be  tp  to  date.  Bad  information  can't  persist  forever  by  being 
passed  around  from  machine  to  machine;  the  only  bad  information 
that  can  exist  is  in  a  machine  that  doesn’t  know  that  some  other 
machine  has  changed  its  48. bit  Ethernet  address.  Perhaps 
manually  resetting  (or  clearing)  the  address  mapping  table  will 
suffice. 

This  issue  clearly  needs  more  thought  if  it  is  believed  to  be 
inportant.  It  is  caused  by  any  address  resolution- like  protocol. 
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8.  As  ■entJ.oned,  SARP  requires  tiiatc  server  tiosts  ealntaln  large 
databases.  It  Is  tfvieslrable  and  In  sane  cases  Ixpossible  to  eaintaln 
sucti  a  database  in  tl)e  kernel  of  e  host's  operating  systee.  Thus, 
■ost  liq>leaentatlons  will  require  sone  fore  of  interaction  with  a 
pro^-ae  outside  the  kernel. 


C.  Ease  of  liqpleeentatiGc;  and  eintsal  izpact  cn  erlsting  host 
softuare  are  iifwrtant.  It  would  be  a  el  stake  to  desi^i  a  protocol 
that  required  eodifications  to  every  host's  software,  idiether  or  not 
it  intended  to  participate. 

D.  It  is  desirable  to  allow  for  the  possibility  of  sharing  code  with 

existing  software,  to  overhead  and  developaent  costs. 

I.  The  Proposed  Pr»'toool 

Me  prepose  that  RARP  be  specified  as  a  separate  protocol  at  the 
deta^link  lewel.  For  exaeple.  if  the  aedliai  used  is  Ethernet,  then 
RASP  parkers  will  bawe  an  Ethertyee  fstlll  to  be  assigned)  different 
from  that  of  ARP.  This  reoogilz»  tint  ARP  and  RARP  are  two 
fundbMncally  differeist  operations,  not  supported  equally  by  all 
hosts.  The  l^iact  on  existing  systens  is  Blnislzed:  existing  ARP 
■eraerr  will  not  be  confused  by  EARP  packets.  It  sakes  RARP  a  general 
facility  that  can  be  used  for  sapping  harctare  addresses  to  any 
bighsa^  leael  protocol  address. 


This  approach  prowldes  the  siaplest  laplesentation  for  RARP  client 
hosts,  but  also  provides  the  aost  difficulties  for  RARP  server  hosts. 
However,  these  di  '.ficulties  should  not  be  .nsursountable.  as  is  shown 
In  Appendix  K  «iwre  we  sketch  two  possible  l^plesentations  for 
4.2flSD  UrJuL. 


lARP 


packet  format  that  is  used  by  ARP. 


arStord  (harduare  address  space)  '  16  bits 

ao 4|iiiu  ^irotoool  address  space)  *  16  bits 

arlFbln  pwdWare  aAl'-sss  length)  '  8  bits 
ar  ^In  ^ctocal  address  l^tgth)  *  8  bits 
9rS43p  (opcode)  '  16  bits 
arKSha  (source  hardware  address)  *  n  bytes. 

where  n  is  from  the  arshin  field. 
arSspa  (source  protocol  address)  '  a  bytes. 

there  a  is  froa  the  ar^ln  field. 
arStha  (target  hard^sre  -  r  bytes 

affStpa  {target  protocol  address)  *  a  bytes 


arthrd.  arSpro.  arShln  and  arSplr  are  the 
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Suppose,  for  example,  that:  'hardware*  addresses  are  48-blt  Ethernet 
addresses,  and  'protocol*  addresses  are  32-blt  Internet  Adklresses. 
That  is,  we  wish  to  determine  Internet  Addresses  corre^x^ndlng  to 
known  Ethernet  addresses.  Then,  In  eacdi  RARP  pacdcet,  ar$hrd  =  1 
(Ethernet) ,  ar$pro  =  2048  decimal  (the  Ethertype  of  IP  packets) , 
arshin  =  6,  and  ar^ln  =  4. 

There  are  two  opcodes:  3  ('request  reverse')  and  4  ('reply  reverse')  . 
An  opcode  of  1  or  2  has  tte  sane  meaning  as  In  [1]  ;  packets  with  su^ 
opcodes  may  be  passed  on  to  regular  ARP  code.  A  packet  with  any 
other  opcode  Is  undefined.  As  in  ARP,  there  are  no  "not  found"  or 
"error"  packets,  since  many  RARP  servers  are  free  to  respond  to  a 
re(|uest.  The  sender  of  a  PARP  request  packet  should  timeout  If  It 
does  not  receive  a  reply  for  this  rec|uest  within  a  reasonable  amount 
of  time. 

The  ar$sha,  ar$spa,  9ar$tha,  and  ar$tpa  fields  of  the  RARP  packet  are 
Interpreted  as  follows: 

Itm  the  opcode  Is  3  ('request  reverse')  : 

ar$sha  Is  the  hardware  address  of  the  sender  of  the  packet. 

ar$spa  Is  undefined. 

ar$tha  Is  the  'target*  hardware  address. 

In  the  case  idiere  the  sender  wishes  to  determine  his  own 
protocol  address,  this,  like  ar$sha,  will  be  the  hardware 
address  of  the  sender. 

ar$tpa  Is  isideflned. 

Itien  the  opcode  Js  4  ('reply  reverse')  : 

ar$^)a  Is  the  hardware  address  of  the  responder  (the  sender  of  the 
reply  packet)  . 

ar$spa  is  the  protocol  address  of  the  responder  (see  the  note 
below)  . 

ar$tha  Is  the  hardware  address  of  the  target,  and  should  be  the 
same  as  that  idiich  was  given  In  the  reqfuest. 

ar$tpa  is  the  protocol  address  of  the  target,  that  is,  the  desired 
address. 

Note  that  the  requirement  that  ar^spa  In  opcode  4  packets  be  filled 
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in  with  the  responder's  protocol  is  purely  for  convenience.  For 
instance,  if  a  system  were  to  use  both  ARP  and  RARP,  then  the 
inclusion  of  the  valid  protocol -hardware  address  pair  (ar$^a, 
ar$sha)  may  eliminate  the  need  for  a  subsequent  ARP  request. 

I^.  References 

[1]  Pluimner,  D.,  "An  Ethernet  Address  Resolution  Protocol",  RFC  826, 
MIT-LCS,  November  1982. 

^^pendlx  A.  Two  Exaiqple  Iiqplementations  for  4.2BSD  Unix 

Ihe  following  implementation  fetches  outline  two  different 
approaches  to  Inplemoiting  a  RARP  server  under  4.2BSD. 

A.  Provide  access  to  data-link  level  packets  outside  the  kernel .  Ihe 
RARP  server  is  Implemgited  completely  outside  the  kernel  and 
interacts  with  the  kernel  only  to  receive  and  send  RARP  packets.  The 
kernel  has  to  be  modified  to  provide  the  appropriate  access  for  these 
packets;  currently  the  4.2  kernel  allows  access  only  to  IP  packets. 
One  existing  mechanism  that  provides  this  capability  is  the  CMU 
"packet- filter"  pseudo  driver.  This  hais  been  used  successfully  at 
CMU  and  Stanford  to  implement  similar  sorts  of  "user -level"  network 
servers . 

B.  Maintain  a  cache  of  database  entries  inside  the  kernel.  Ihe  full 
RARP  server  database  is  maintained  outside  the  kernel  by  a  user 
process.  The  RARP  server  itself  is  Implemented  directly  in  the 
kernel  and  enploys  a  small  cache  of  database  entries  for  its 
responses.  This  cache  could  be  the  same  as  is  used  for  forward  ARP. 

Ihe  cache  gets  filled  from  the  actual  RARP  database  by  means  of  two 
new  ioctls.  (These  are  like  SIOCIFADDR,  in  that  they  are  not  really 
associated  wi^  a  specific  socket.)  One  means;  "sle^  until  there  is 
a  translation  to  be  done,  then  pass  the  request  out  to  the  user 
process'';  the  other  means;  "enter  this  translation  into  the  kernel 
table".  Thus,  when  the  kernel  can't  find  an  entry  in  the  cache,  it 
puts  the  request  on  a  (global)  queue  and  then  does  a  wakeip()  .  The 
implementation  of  the  first  ioctl  is  to  sle^O  and  then  pull  the 
first  item  off  of  this  queue  and  return  it  to  the  user  process. 

Since  the  kernel  can't  wait  around  at  internpt  level  until  the  user 
process  relies,  it  can  either  give  up  (and  assume  that  the 
recpiesting  host  will  retransmit  the  request  packet  after  a  second)  or 
if  the  second  ioctl  passes  a  copy  of  the  request  back  into  the 
kernel,  formulate  and  send  a  response  at  that  time. 
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Preface  (Status  of  this  Memo) 

This  document  specifies  the  Host  Access  Protocol  (HAP)  . 
Althouc^  HAP  was  originally  designed  as  the  network- access  level 
protocol  for  the  DARPA/DCA  sponsored  Wideband  Packet  Satellite 
Network,  it  is  intended  that  it  evolve  into  a  standard  interface 
between  hosts  and  packet -switched  satellite  networks  such  as 
SATNET  and  TACNET  (aka  MATNET)  as  well  as  the  Wideband  Network. 
The  HAP  specification  presented  here  is  a  minor  revision  of,  and 
supercedes,  the  specification  presented  in  Chapter  4  of  BBN 
Report  No.  4469,  the  ’*PSAT  Technical  Report”.  As  such,  the 
details  of  the  current  specification  are  still  most  closely 
matched  to  the  characteristics  if  the  Wideband  Satellite  Network. 
Revisions  to  the  specification  in  the  ”PSAT  Technical  Report” 
Include  the  definition  of  three  now  control  message  types 
(Loojf^ack  Request,  Link  Going  Down,  and  NOP) ,  a  "Reason”  field  in 
Restart  Request  control  messages,  now  Unnumbered  Response  codes, 
and  new  values  for  the  setup  codes  used  to  manage  streams  and 
groups. 

HAP  is  an  ejpcrimental  protocol,  and  will  undergo  further 
revision  as  new  capabilities  are  added  and/or  different  satellite 
networks  are  sup^rted.  Isplementations  of  HAP  should  be 
performed  in  coordination  with  satellite  network  development  and 
operations  personnel. 
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1  Introduction 

The  Hust  Access  Protocol  (HAP)  specifies  the  network- access 
level  coaounication  between  an  arbitrary  coiqputer,  called  a  host, 
and  a  packet-switched  satellite  network.  The  satellite  network 
provides  message  delivery  services  for  geographically  separated 
hosts:  Messages  containing  data  %fhich  are  meaningful  to  the  hosts 
are  submitted  to  the  network  by  an  originating  (source)  host,  and 
are  passed  transparently  through  the  network  to  an  indicated 
destination  host.  To  utilize  such  services,  a  host  interfaces  to 
the  satellite  network  via  an  access  link  to  a  dedicated  packet¬ 
switching  cogputer,  known  as  a  Satellite  Interface  Message 
Processor  (Satellite  IMP  or  SIMP) .  HAP  defines  the  different 
types  of  control  messages  and  (host -to -host)  data  messages  that 
may  be  exchanged  over  the  access  link  connecting  a  host  and  a 
SIMP.  The  protocol  establishes  formats  for  these  messages,  and 
describes  procedures  for  determining  when  each  type  of  message 
should  be  transmitted  and  what  it  means  when  one  is  received. 

The  term  "Interface  Message  Processor originates  in  the 
ARPANET,  where  it  refers  to  the  ARPANET'S  packet -switching  nodes. 
SIMPs  differ  from  ARPANET  IMPS  in  that  SIMPs  form  a  network  via 
connections  to  a  cosnon  multiaccess./broadcast  satellite  channel, 
whereas  ARPANET  IMPS  are  interconnected  by  dedicated  point  to - 
point  terrestrial  coemunications  lines.  This  fundamental 
difference  between  satellite-based  and  ARPANET-style  networks 
results  in  different  mechanisms  for  the  delivery  of  messages  from 
source  to  destination  hosts  and  for  internal  network 
coordination.  Additionally,  satellite  networks  tend  to  offer 
different  type  of  service  options  to  their  connected  hosts  than 
do  ARPANET-style  networks.  ‘n»ese  options  are  included  in  the 
Host  Access  Protocol  presented  here. 

Several  types  of  Satellite  IMPs  have  been  developed  on  a 
variety  of  processors  for  the  support  of  three  different  packet- 
switched  satellite  networks.  The  original  SIMP  was  esployed  in 
the  Atlantic  Packet  Satellite  Network  (SATINET)  .  It  was  developed 
from  one  of  the  models  of  ARPANET  IMP,  and  was  iaplemented  on  a 
Honeywell  316  minicoeputer .  The  316  SIF^s  were  succeeded  in 
SATNET  by  SIMPs  based  on  BBN  C/30  CocuBunl  cat  ions  Processor 
hardware.  The  C/30  SIMPs  have  also  been  eeployed  in  the  Mobile 
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Access  Terminal  Network  (MATNET)  .  The  SA3NET  and  MAINET  SIMPs 
inplement  a  network- access  level  protocol  known  as  Host/SATNET 
Protocol.  Host/SATNET  Protocol  is  the  precursor  to  HAP  and  is 
documented  in  Internet  Esqperiment  Note  (lEN)  No.  192.  The 
Wid^and  Satellite  Network^  like  SATNET,  has  undergone  an 
evolution  in  the  development  of  its  SIMP  hardware  and  software. 
Ihe  original  Wideband  Network  SIMP  is  known  as  the  Pluribus 
Satellite  IMP,  or  PSAT,  having  been  inplemented  on  the  BBN 
Pluribus  Multiprocessor.  Its  successor,  the  BSAT,  is  based  on 
the  BBN  Butterfly  Multiprocessor.  Both  the  PSAT  and  the  BSAT 
caxDunicate  with  their  connected  network  hosts  via  HAP. 
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2  Overview 

HAP  can  be  characterized  as  a  full  duplex  nonreliable 
protocol  with  an  optional  flow  control  mechanism.  HAP  messages 
flow  simultaneously  in  both  directions  between  the  SIMP  and  the 
host.  Transmission  is  nonreliable  in  the  sense  that  the  protocol 
does  not  provide  any  guarantee  of  error -free  sequenced  delivery. 
To  the  extent  that  this  functionality  is  required  on  the  access 
link  (e.g.,  non-col  located  5IMP  and  host  operating  over  a 
coomrunication  circuit) ,  it  must  be  supported  by  tha  link- level 
protocol  below  HAP .  The  flow  control  mechanism  operates 
indQ>endently  in  each  direction  excqpt  that  enabling  or  disabling 
the  mechanism  applies  to  both  sides  of  the  interface. 

HAP  supports  host-to-host  coamunication  in  two  modes 
corresponding  to  the  two  types  of  HAP  data  messages,  datagram 
message  and  stream  messages.  Each  type  of  message  can  be  ip  to 
ipproximately  16K  bits  in  length.  Datagram  messages  provide  the 
basic  transmission  service  in  the  satellite  network.  Datagram 
messages  transmitted  by  a  host  experience  a  nominal  two  satellite 
hop  end-to-end  network  delay.  (Note  that  this  delay,  of  about  0.6 
sec  excluding  access  link  delay,  is  associated  with  datagram 
transmission  between  hosts  on  different  SIMPs.  The  transmission 
delay  between  hosts  on  the  same  SIMP  will  be  much  smaller 
assuming  the  destination  is  not  a  group  address.  See  Section  3 
and  6.2.)  A  datagram  control  header,  passed  to  the  SIMP  by  the 
host  along  with  message  text,  determines  the  processing  of  the 
message  within  the  satellite  network  independent  of  any  previous 
exchanges. 

Stream  messages  provide  a  one  satellite  hop  delay 
(approximately  0.3  sec)  for  volatile  traffic,  such  as  speech, 
which  cannot  tolerate  the  delay  associated  with  datagram 
transmission.  Hosts  may  also  use  streams  to  support  hi duty 
cycle  applications  which  require  guaranteed  channel  bandwidt)'*. 
Host  streams  are  established  by  a  setup  message  exchange  between 
the  host  and  the  network  prior  to  the  cooDencement  of  data  flow. 
Althou^  established  host  streams  can  have  their  characteristics 
sodified  by  subsequent  setup  messages  while  thcry  are  in  use,  the 
fixed  allocation  properties  of  streams  relative  to  datagrams 
iopose  rather  strict  requirements  on  the  source  of  the  traffic 
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using  the  stream.  Stream  traffic  arrivals  mxist  match  the  stream 
allocation  both  in  interarrival  time  and  message  size  if 


codsuiioble  ef ficic3iiSi«y  is  tc  be  aChieV'ed  .  characteristics  and 
use  of  datagrams  and  streams  are  described  in  detail  in  Sections 
3  and  4  of  this  document. 

Both  datagram  and  stream  transmission  in  the  satellite 
network  use  logical  addressing.  Each  host  on  the  network  is 
assigned  a  permanent  16 -bit  logical  address  which  is  independent 
of  the  physical  port  on  the  SIMP  to  which  it  is  attached.  These 
16-bit  logical  addresses  are  provided  in  all  Host-to-SIMP  and 
SIMP-to-Host  data  messages. 

Hosts  may  also  be  members  of  groups.  Group  addressing  is 
provided  primarily  to  support  the  multi -destination  delivery 
required  for  conferencing  applications.  Like  streams,  group 
addresses  are  dynamically  created  and  deleted  by  the  use  of  setup 
messages  exchanged  between  a  host  and  the  network.  Membership  in 
a  group  may  consist  of  an  arbitrary  subset  of  all  the  permanent 
network  hosts.  A  message  addressed  to  a  group  address  Is 
delivered  to  all  hosts  that  are  members  of  that  group. 

Although  HAP  does  not  guarantee  error -free  delivery,  error 
control  is  an  liiportant  aspect  of  the  protocol  design.  HAP  error 
control  is  concerned  with  both  local  transfers  between  a  host  and 
its  local  SIMP  and  transfers  from  SIMP-to-SIMP  over  the  satellite 
channel.  The  SIMP  offers  users  a  choice  of  network  error 
protection  options  based  on  the  network's  ability  to  selectively 
send  mesfiages  over  the  satellite  channel  at  different  coding 
rates.  These  for ward  error  correction  (FEC)  options  are  referred 
to  as  reliability  levels.  Three  reliability  levels  (low,  medium, 
and  hi^)  are  available  to  the  host. 

In  addition  to  forward  error  correction,  a  number  of 
checksum  mechanisms  are  enployed  in  the  satellite  network  to  add 
an  error  detection  capability.  A  host  has  an  opportunity  when 
sending  a  message  to  indicate  whether  the  message  should  be 
delivered  to  its  destination  or  discarded  if  a  data  error  is 
dfjtected  by  the  network.  Each  message  received  ly  a  host  from 
the  network  will  have  a  flag  indicating  whether  or  not  an  error 
was  detected  in  that  particular  message.  A  host  can  decide  on  a 
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per -message  basis  whether  or  not  it  wants  to  accept  or  discard 
transmissions  containing  data  errors. 

For  connection  of  a  host  and  SIMP  in  close  proximity,  error 
rates  due  to  external  noise  or  hardware  failures  on  the  access 
circuit  may  reasonably  be  expected  to  be  much  smaller  than  the 
best  satellite  channel  error  rate.  Thus  for  this  case,  little  is 
gained  by  using  error  detection  and  retransmission  on  the  access 
circuit.  A  16 -bit  header  checksum  is  provided,  however,  to 
insure  that  SIMPs  do  not  act  on  incorrect  control  information. 
For  relatively  long  distances  or  noisy  connections, 
retransmissions  over  the  access  circuit  may  be  required  to 
optimize  performance  for  both  low  and  hi^  reliability  traffic. 
It  is  expected  that  link- level  error  control  procedures  (such  as 
HDLC)  will  be  used  for  this  purpose. 

Datagram  and  stream  messages  being  presented  to  the  network 
by  a  host  may  not  be  accepted  for  a  nuniber  of  reasons;  priority 
too  low,  destination  dead,  lack  of  buffers  in  the  source  SIMP, 
etc.  Ihe  host  faces  a  similar  situation  with  respect  to  handling 
messages  from  the  SIMP.  To  permit  the  receiver  of  a  message  to 
inform  the  sender  of  the  local  disposition  of  its  message,  an 
acceptance/refusal  (A/R)  mechanism  is  implemented.  Ihe  mechanism 
is  the  external  manifestation  of  the  SIMP's  (or  host's)  internal 
flow  and  congestion  control  algorithm.  If  A/Rs  are  enabled,  an 
explicit  or  implicit  acceptance  or  refusal  for  each  message  is 
returned  to  the  host  by  the  SIMP  (and  conversely)  .  This  allows 
the  host  (or  SIMP)  to  retry  refused  messages  at  its  discretion 
and  can  provide  information  useful  for  optimizing  the  sending  of 
subsequent  messages  if  the  reason  for  refusals  is  also  provided. 
The  A/R  mechanism  can  be  disabled  to  provide  a  "pure  discard" 
interface. 

Each  message  submitted  to  the  SIMP  by  a  host  is  marked  as 
being  in  one  of  four  priority  classes,  from  priority  3  (highest) 
through  priority  0  (lowest)  .  The  priority  class  is  used  by  the 
SIMP  for  arbitrating  contention  for  scarce  network  resources 
(e.g.,  channel  time).  That  is,  if  the  network  cannot  deliver  all 
of  the  offered  messages,  high  priority  messages  will  be  delivered 
in  preference  to  low  priority  messages.  In  the  case  of 
datagrams,  priority  level  is  used  by  the  SIMP  for  ordering 
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satellite  channel  reservation  requests  at  the  source  SIMP  and 
message  delivery  at  the  destination  SIMP.  In  the  case  of 
streams^  prioritTy  Is  associated  With  the  ahility  of  one  stream  tc 
preeirpt  another  stream  of  lower  priority  at  setup  time. 

While  the  A/R  mechanism  allows  control  of  individual  message 
transfers,  it  does  not  facilitate  regulation  of  priority  flows. 
Such  regulation  is  handled  by  passing  advisory  status  information 
(GOPRI)  across  the  Host-SIMP  interface  indicating  which 
priorities  are  currently  being  accepted.  As  long  as  this 
information,  relative  to  the  change  in  priority  status,  is  passed 
frequently,  the  sender  can  avoid  originating  messages  which  are 
sure  to  be  refused. 

HAP  defines  both  data  messages  (datagram  messages  and  stream 
messages)  and  control  messages.  Data  messages  are  used  to  send 
information  between  network  hosts.  Control  messages  are 
exchanged  between  a  host  and  the  network  to  manage  the  local 
access  link.  HAP  can  also  be  viewed  in  terms  of  two  distinct 
protocol  layers,  the  message  layer  and  the  setxxp  layer.  The 
message  layer  is  associated  with  the  transmission  of  individual 
datagram  messages  and  stream  messages.  The  setup  layer  protocol 
is  associated  with  the  establishment,  modification,  and  deletion 
of  streams  and  groups.  Setup  layer  exchanges  are  actually 
Inplemented  as  datagrams  transmitted  between  the  user  host  and  an 
internal  SIMP  "service  host." 

Every  HAP  message  consists  of  an  integral  number  of  16-bit 
words.  The  first  several  words  of  the  message  always  contain 
control  information  and  are  referred  to  as  the  message  header. 
The  first  word  of  the  message  header  identifies  the  type  of 
message  which  follows.  The  second  word  of  the  message  header  is 
a  checksum  which  covers  all  header  Information.  Any  message 
whose  received  header  checksum  does  not  match  the  checksum 
conputed  on  the  received  header  information  must  be  discarded. 
The  format  of  the  rest  of  the  header  depends  on  the  specific 
message  tyoe. 

The  forma cs  and  use  of  the  individual  message  types  are 
detailed  in  the  following  sections.  A  common  format  description 
is  used  for  this  purpose.  Words  in  a  message  are  numbered 
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starting  at  zero  (i.e.,  zero  is  the  first  word  o^  a  message 
header)  .  Bits  within  a  word  are  nmnbered  from  zero  (least 
significant)  to  fifteen  (most  significant)  .  Ihe  notation  used  to 
identify  a  particular  field  location  is: 

<W0RD#>{-<W0RD#>}  [  <BIT#>{-<BIT#>}  ]  <descriptlon> 

where  optional  elements  in  {}  are  used  to  specify  the  (inclusive) 
upper  limit  of  a  range.  The  reader  should  refer  to  these  field 
identifiers  for  precise  field  size  specifications.  Fields  which 
are  common  to  several  message  types  are  defined  in  the  first 
section  which  uses  them.  Only  the  name  of  the  field  will  usually 
appear  in  the  descriptions  in  subsequent  sections. 

Link- level  protocols  used  to  support  HAP  can  differ  in  the 
order  in  which  they  transmit  the  bits  constituting  HAP  messages. 
For  HDLC  and  ARPANET  VDH,  each  word  of  a  HAP  message  is 
transmitted  starting  with  the  least  significant  bit  (bit  0)  and 
ending  with  the  most  significant  bit  (bit  15)  .  The  words  of  the 
message  are  transmitted  from  word  0  to  word  N.  For  ARPANET  1822 
local  and  distant  host  Interfaces,  the  order  of  bit  transmission 
within  each  word  is  the  reverse  of  that  for  HDLC  and  VDH,  i.e., 
the  transmission  is  from  bit  15  to  bit  0. 
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3  Datagram  Messages 

Datagram  messages  are  one  of  the  two  types  of  message  level 
data  messages  used  to  support  host-to-host  communication.  Each 
datagram  can  contain  up  to  16^384  bits  of  user  data.  Datagram 
messages  transmitted  by  a  host  to  a  host  on  a  remote  SIMP 
experience  a  nominal  two  satellite  hop  end-to-end  network  delay 
(about  0.6  sec),  excluding  delay  on  the  access  links.  This 
network  delay  is  due  to  the  reservation  per  message  scheduling 
procedure  for  datagrams  which  only  allocates  channel  time  to  the 
message  for  the  duration  of  the  actual  transfer.  Since  datagram 
transfers  between  permanent  hosts  on  the  same  SIMP  do  not  require 
satellite  channel  scheduling  prior  to  data  transmission,  the 
n'^twork  delay  in  this  case  will  be  much  smaller  and  is  determined 
strictly  by  SIMP  processing  time .  Datagrams  sent  to  group 
addresses  are  treated  as  if  they  were  addressed  to  remote  hosts 
and  are  always  sent  over  the  satellite  channel .  It  is  expected 
that  datagram  messages  will  be  used  to  support  the  majority  of 
computer- to-conputer  and  terminal -to -computer  traffic  which  is 
bursty  in  nature. 
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0  1  OjLBlGOPRII  XXXX  j  F|  MESSAGE  NUMBER  \ 

1  j  HEADER  CHECKSUM  | 

2  1  A/R  I 

3  !  0|IL|  D|  E|  TTL  I  PRI  I  RLY  |  RLEN  j 

4  I  DESTINATION  HOST  ADDRESS  | 

5  I  SOURCE  HOST  ADDRESS  | 

6-N  I  DATA  I 


Figure  1  .  DATAGRAM  MESSAGE 


0[15]  Message  Class.  Tliis  bit  identifies  the  message  as  a 
data  message  or  a  control  message. 

0  =  Data  Message 
1  =  Control  Message 

0 [14]  Loopback  Bit.  This  bit  allows  the  sender  of  a  message 
to  determine  if  its  own  messages  are  being  looped  back. 
The  host  and  the  SIMP  each  use  different  settings  of 
this  bit  for  their  transmissions .  If  a  message  arrives 
with  the  loopback  bit  set  equal  to  its  outgoing  value, 
then  the  message  has  been  looped. 

0  =  Sent  by  Host 
1  =  Sent  by  SIMP 


A  *  ‘ 
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Go-Priority.  In  SIMP-to-Host  messages,  this  field 
provides  advisory  information  concerning  the  lowest 
priority  currently  iDcing  accepted  ^'^y  the  SIMP  • 
host  may  optionally  choose  to  provide  similar  priority 
information  to  the  SIMP. 

0  =  Low  Priority 

1  =  Mediim-Low  Priority 

2  =  Medium-Hig^  Priority 

3  =  Hlgjti  Priority 

Reserved. 

Force  Channel  Transmission  Flag.  This  flag  can  be  set 
by  the  source  host  to  force  the  SIMP  to  transmit  the 
message  over  the  satellite  channel  even  if  the  message 
contains  permanent  destination  and  source  host 
addresses  corresponding  to  hosts  which  are  physically 
connected  to  the  same  SIMP. 

0  =  Normal  operation 
1  =  Force  channel  transmission 

Message  Number.  This  field  contains  the  identification 
of  the  message  used  by  the  accqptance/refusal  (A/R) 
mechanism  (when  enabled)  .  If  the  message  number  is 
zero,  A/R  is  disabled  for  this  specific  message.  See 
Section  5  for  a  detailed  description  of  the  A/R 
mechanism. 

Header  Checksum.  This  field  contains  a  checksum  which 
covers  words  0-5.  It  is  computed  as  the  negation  of 
the  2's-coiBplcment  sum  of  words  0-5  (excluding  the 
checksum  word  itself) . 

Piggybacked  A/R.  This  field  may  contain  an 
acceptanco/refusal  word  providing  A/R  status  on  traffic 
flowing  in  the  opposite  direction.  Its  inclusion  may 
eliminate  the  need  for  a  separate  A/R  control  message 
(see  Section  5) .  A  value  of  zero  for  this  word  is  used 
to  indicate  that  no  piggybacked  A/R  information  is 
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present . 

Data  I’tessage  Type.  bit  identifies  ^fhsther  the 

message  is  a  datagram  message  or  a  stream  message. 

0  =  Datagram  Message 
1  =  Stream  Message 

Intemet/Local  Flag.  This  flag  is  set  by  a  source  host 
to  specify  to  a  destination  host  whether  the  data 
portion  of  the  message  contains  a  standard  DoD  Internet 
header.  This  field  is  passed  transparently  by  the 
source  and  destination  SIMPs  for  traffic  between 
external  i.atellite  network  hosts.  This  field  is 
examined  by  internal  SIMP  hosts  (e .  g . ,  the  network 
service  host)  in  order  to  support  Internet  operation. 

0  =  Internet 
1  =  Local 


Discard  Flag.  This  flag  allows  a  source  host  to 
lnstnju:t  the  satellite  network  (Including  the 
destination  host)  what  to  do  with  the  message  when  data 
errors  are  detected  (assuming  the  header  checksum  is 
correct) . 

0  =  Discard  message  if  data  errors  detected. 

1  =  Don't  discard  message  if  data  errors  detected. 


The  value  of  this  flag,  set  by  the  source  host,  is 
passed  on  to  the  destination  host. 

Data  Error  Flag.  This  flag  is  used  in  conjunction  with 
the  Discard  Flag  to  Indicate  to  the  destination  host 
whether  any  data  errors  have  been  detected  in  the 
message  prior  to  transmission  over  the  SIMP-to-Host 
access  link.  It  is  used  only  if  Discard  Flag  =1.  It 
should  be  set  to  zero  by  the  source  host. 
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3  [10-11] 


3 [8-9] 


0  =  No  Data  Errors  Detected 
1  =  Data  Errors  Detected 


Time- to -Live  Designator.  The  source  host  uses  this 
field  to  specify  the  maxi  mum  time  that  a  message 
should  be  allowed  to  exist  within  the  satellite  network 
before  being  deleted.  Messages  may  be  discarded  by  the 
network  prior  to  this  maximum  elapsed  time. 

0=1  seconds 
1=2  seconds 
2=5  seconds 
3  =  10  seconds 


The  Time- to -Live  field  is  undefined  in  messages  sent 
from  a  SIMP  to  a  host. 

Priority.  The  source  host  uses  this  field  to  specify 
the  priority  with  which  the  message  should  be  hkndled 
within  the  network. 

0  =  Low  Priority 

1  =  Medium-Low  Priority 

2  =  Medium-Hi^^  Priority 

3  =  High  Priority 


The  priority  of  each  message  is  passed  to  the 
destination  host  by  the  destination  SIMP. 

3  [6-7]  Reliability .  The  source  host  uses  this  field  to 
sp€>clfy  the  basic  bit  error  rate  requirement  for  the 
data  portion  of  this  message.  The  source  SIMP  uses 
this  field  to  determine  the  satellite  channel 
transmission  parameters  required  to  provide  that  bit 
error  rate. 

0  =  Low  Reliability 
1  =  Medium  Reliability 
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3 [0-5] 


4 [0-15] 


5 [0-15] 


2  =  Hl^  Reliability 

3  =  Reserved 


The  Reliability  field  is  undefined  in  messages  sent 
from  a  SIMP  to  a  host. 

Reliability  Length.  This  source  host  uses  this  field 
to  specify  a  portion  of  the  user  data  which  should  be 
transmitted  at  the  highest  reliability  level  (lowest 
bit  error  rate)  .  Both  the  six  message  header  words  and 
the  first  Reliability  Length  words  of  user  data  will  be 
transmitted  at  Reliability=2  while  the  remainder  of  the 
user  data  will  be  transmitted  at  whatever  reliability 
level  is  i^MCified  in  field  3[6-7] .  The  reliability 
length  mechanism  gives  the  user  the  ability  to  transmit 
private  header  information  (e.g.«  IP  and  TCP  headers) 
at  a  higher  reliability  level  than  the  remainder  of  the 
data.  The  Reliability  Length  field  is  undefined  in 
messages  sent  from  a  SIMP  to  a  host. 

Destination  Host  Address.  This  field  contains  the 
satellite  network  logical  address  of  the  destination 
host. 

Source  Host  Address.  This  field  contains  the  satellite 
network  logical  address  of  the  source  host. 

Data.  This  field  contains  uqp  to  16,384  bits  (1024  16- 

bit  words)  of  user  data. 
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4  Stream  Messages 

Stream  messages  are  the  second  type  of  message  level  data 
messages.  As  noted  in  Section  2,  streams  exist  primarily  to 
provide  a  one  satellite  hop  delay  for  volatile  traffic  such  as 
speech.  Hosts  may  also  use  streams  to  support  hig^  duty  cycle 
applications  which  require  guaranteed  char  nel  bandwidth. 

Streams  must  be  created  before  stream  messages  can  flow  from 
host  to  host.  The  protocol  to  acconplish  stream  creation  is 
described  in  Section  6.1.  Once  established,  a  stream  is 
associated  with  a  recurring  channel  allocation  within  the 
satellite  network.  This  fixed  allocation  iiqposes  rather  strict 
requirements  on  the  host  using  the  stream  if  efficient  channel 
utilization  is  to  be  achieved.  In  particular,  stream  messages 
must  match  the  stream  allocation  both  in  terms  of  message  size 
and  message  interarrival  time. 

Within  the  bounds  of  its  *  stream  allocation,  a  host  is 
permitted  considerable  flexibility  in  how  it  may  use  a  stream. 
Although  the  priority,  reliability,  and  reliability  length  of 
each  stream  message  is  fixed  at  stream  creation  time,  the 
destination  logical  address  can  vary  from  stream  message  to 
stream  message.  A  host  can,  therefore,  multiplex  a  variety  of 
logical  flows  onto  a  single  host  stream.  The  format  of  stream 
messages  is  described  in  Figure  2. 
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I  0|LB|GOPRI|  XXXX  |  MESSAGE  NUMBER  | 
I  HEADER  CHECKSUM  i 


I  1|IL|  Dj  E|  TTL  I  HOST  STREAM  ID 

I  DESTINATION  HOST  ADDRESS 


SOURCE  HOST  AI^»ESS 


DATA 


0C15] 

0[14] 


Figure  2  .  STREAM  MESSAGE 


Message  Class  =  0  (Data  Message) . 


Loopback  Bit. 


0 [12-13]  Go-Priority. 

O[0-ll]  Reserved. 

0[0-7]  Message  Number.  This  field  serves  the  same  purpose  as 
the  message  number  field  in  the  datagram  message. 
Moreover,  a  single  message  number  sequence  is  used  for 
both  datagram  and  stream  messages  (see  Section  5) . 

iro-15]  Header  Checksum.  Covers  Words  0-5. 

2[0-15]  Piggybacked  A/R. 
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3  [15] 
3  [14] 
3  [13] 
3  [12] 


Data  Message  Type  =  1  (Stream) . 
Intemet/Local  Flag. 

Discard  Flag. 

Data  Error  Flag. 


3[10-11]  Timo-to- live  Designator. 

0  =  Reserved 

1=1  second 

2  =  Reserved 

3  =  Reserved 

3 [0-9]  Host  Stream  ID.  'D-iO  service  host  uses  this  field  to 
identify  the  host  stream  over  which  the  message  is  to 
be  sent  by  the  SIMP.  Host  stream  IDs  are  established 
at  stream  creation  time  via  host  exchanges  with  their 
network  service  host  (see  Section  6.1)  . 

4 [0-15]  Destination  Host  Address. 

5 [0-15]  Source  Host  Address. 

6-N  Data.  This  field  contains  up  to  16,000  bits  of  user 

data  (multiple  of  16 -bits)  . 
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5  Flow  Control  Messages 

The  SIMP  supports  an  acceptance/refusal  (A/R)  mechanism  In 
each  direction  on  the  host  access  link.  The  A/R  mechanism  Is 
enabled  for  the  link  by  the  host  by  setting  a  bit  In  the  Restart 
Cooplete  control  message  (see  Section  8)  .  Each  datagram  and 
stream  message  contains  an  8 -bit  message  number  us€»d  to  Identify 
the  message  for  flow  control  purposes.  Both  the  host  and  the 
SIMP  Increment  this  number  modulo  256  In  successive  messages  they 
transmit.  Up  to  127  messages  may  be  outstanding  In  each 
direction  at  any  time.  If  the  recolver  of  a  message  Is  unable  to 
accept  the  message^  a  refusal  Indication  containing  the  message 
number  of  the  refused  message  and  the  reason  for  the  refusal  Is 
returned.  The  refusal  Indication  may  be  piggybacked  on  data 
messages  in  the  opposite  direction  over  the  link  or  may  be  sent 
In  a  separate  control  message  In  the  absence  of  reverse  traffic. 

Acceptance  Indications  are  returned  In  a  similar  manner, 
either  piggybacked  on  data  messages  or  In  a  separate  control 
message.  An  acceptance  Is  returned  by  the  receiver  to  Indicate 
that  the  Identified  message  was  not  refused.  Acceptance 
Indications  returned  by  the  SIMP  do  not,  ho%#ever,  isply  a 
guarantee  of  delivery  or  even  any  assurance  that  the  message  will 
not  be  Intentionally  discarded  by  the  network  at  a  later  time. 
They  are  sent  primarily  to  facilitate  buffer  management  In  the 
host. 


To  reduce  the  number  of  A/R  messages  exchanged,  a  single  A/R 
Indication  can  be  returned  for  multiple  (lower  numbered) 
previously  unacknowledged  messages.  Explicit  acceptance  of 
message  nuzzber  N  laplles  lnpliclt  acceptance  of  outstanding 
messages  with  numbers  N-1,  N-2,  etc.,  according  to  the 
definition  of  acc^tance  outlln^  above.  (Note  that  e^liclt 
acceptance  of  message  number  N  does  not  Inply  that  all  of  the 
unacknowledged  outstanding  messages  have  been  received.)  An 
analogous  Interpretation  of  refusal  message  number  allows  the 
r€K:elver  of  a  group  of  messages  to  reject  them  as  a  group 
assuming  that  they  all  are  being  refused  for  the  same  reason.  As 
a  further  efficiency  measure,  HAP  penal  ts  a  block  of  A/R 
Indications  to  be  aggregated  Into  a  single  A/R  control  message. 
Such  a  message  might  be  used,  for  exasple,  to  reject  a  group  of 
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messages  vhere  the  refusal  code  on  each  is  different. 

In  some  circumstances  the  overhead  associated  with 
processing  A/R  messages  may  prove  unattractive.  For  these  cases. 
It  Is  possible  to  disable  the  A/R  mechanism  and  operate  the  HAP 
Interface  In  a  purely  discard  mode.  Ihe  ability  to  effect  this 
on  a  link  basis  has  already  been  noted  (see  Sections  2  and  8)  . 
In  addition,  messages  with  sequence  number  zero  are  taken  as 
messages  for  \^lch  the  A/R  mechanism  Is  selectively  disabled.  To 
permit  critical  feedback,  even  when  operating  in  discard  mode, 
HAP  defines  an  "Unnumbered  Response"  control  message. 

The  format  shown  in  Figure  3  is  used  both  for  piggybacking 
A/R  indications  on  data  messages  (word  2) ,  and  for  providing  A/R 
information  in  separate  control  messages.  When  separate  control 
messages  are  used  to  transmit  A/R  indications,  the  format  shown 
in  Figure  4  applies.  Flow  control  information  and  other 
information  which  cannot  be  sent  as  an  A/R  indication  is  sent  in 
an  Unnumbered  Response  control  message.  The  format  of  this  type 
of  message  is  illustrated  in  Figure  5. 
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lARj  REFUSAL  CODE  |  A/R  MESSAGE  NUMBER  | 

Figure  3  .  ACCEPTANCE/REFUSAL  WORD 


[15]  Acceptance/Refusal  Type.  This  field  identifies  whether 

A/R  information  is  an  acceptance  or  a  refusal. 

9  =  Acceptance 
1  =  Refusal 

[8-14]  Refusal  Code.  When  the  Acceptance/Refusal  Type  =  1, 

this  field  gives  the  Refusal  Code. 

0  =  Priority  not  being  accepted 

1  =  Source  SIMP  congestion 

2  =  Destination  SIMP  congestion 

3  =  Destination  host  dead 

4  =  Destination  SIMP  dead 

5  =  Illegal  destination  host  address 

6  =  Destination  host  access  not  allowed 

7  =  Illegal  source  host  address 

8  =  Message  lost  in  access  link 

9  =  Nonexistent  stream  ID 

10  =  Illegal  source  host  for  stream  ID 

11  =  Message  length  too  long 

12  =  Stream  message  too  early 

13  =  Illegal  conrrol  message  type 

14  =  Illegal  refusal  code  in  A/R 

15  =  Illegal  reliability  value 

16  =  Destination  host  congestion 

[0-7]  A/R  Message  Number.  This  field  contains  the  number  of 
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— +-  f--+- -4— 

0  I  1|LB|G0PRI1  XXXX  |  LENOIH  |  1  | 

1  I  HEADER  CHECKSUM  | 

2  I  A/R  1 


N  I  A/R  I 


Figure  4  .  ACCEPTANCE/REFUSAL  MESSAGE 


0 [15]  Message  Class  =  1  (Control  Message) . 

0  [14]  Loopback  Bit . 

0  [12-13]  Go-Priority. 

0[8-ll]  Reserved. 

0[4-7]  Message  Length.  This  field  contains  the  total  length 
of  this  message  in  words  (N>1)  . 

o[0-3]  Control  Message  Type  =  1  (Acceptance/Refusal)  . 

1[0-15]  Header  Checksum.  The  checksum  covers  words  0-N. 

2  [0-15]  Acceptance/Refusal  Word. 

3-N  Additional  Acceptance/Refusal  Words  (optional) . 
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0  I  1|LB|G0PRI!  XXXX  |  RES-CODE  |  5  | 

1  !  HEADER  CHECKSUM  | 

2  I  RESPONSE  INFO  | 

+--+--+--4---+--+--+--+--+--+ — +  + 

3  j  RESPONSE  INFO  I 

Figure  5  .  UNNUMBERED  RESPONSE 


0  [15]  Message  Class  =  1  (Control  Messqige)  . 

0[14]  Loopback  Bit. 

0 [12-13]  Go-Priority. 

0[8-ll]  Reserved. 

0[4-7]  Response  Code. 


3  =  Destination  unreachable 
5  =  Illegal  destination  host  address 
7  =  Illegal  source  host  address 
9  =  Nonexistent  stream  ID 
10  =  Illegal  stream  ID 
13  =  Protocol  violation 
15  =  Can’t  inplement  loop 

0[0-3]  Control  Message  Typ>e  =  5  (Unnumbered  Response)  . 
1[0-15]  Header  Checksum.  Covers  words  0-3. 
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2  [0-15]  Response  Information.  If  Response  Code  is: 

3^  Destination  Host  Address 
5,  Destination  Host  Address 
1 ,  Source  Host  Address 

9,  Stream  ID  (rig^t  Justified) 

10,  Stream  ID  (right  Justified) 

13,  Word  0  of  offending  message 

15,  Word  0  of  Loopback  Request  message 

3 [0-15]  Response  Information.  If  Response  Code  is: 

3,5,7,  or  9.  Undefined 

10,  Source  Host  Address 

13,  Word  3  of  offending  message,  or  zero  if 
no  word  3 

15,  Word  2  cf  Loopback  Request  message 
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6  Setup  Level  Messages 

Setup  level  protocol  is  provided  to  support  the 
establishment,  modification,  and  deletion  of  groups  and  streams 
in  the  packet  satellite  network.  A  host  wishing  to  perform  one 
of  these  generic  operations  interacts  with  the  network  service 
host  (logical  address  zero) .  The  service  host  causes  the 
requested  action  to  be  carried  out  and  serves  as  the  Intermediary 
between  the  user  and  the  rest  of  the  network.  In  the  process  of 
implementing  the  requested  action,  various  network  data  bases  are 
updated  to  reflect  the  current  state  of  the  referenced  groip  or 
stream . 

The  communication  between  the  host  and  the  service  host  is 
implemented  via  special-purpose  datagrams  called  setup  messages. 
Each  Interaction  initiated  by  a  host  involves  a  3 -way  exchange 
where:  (1)  the  user  host  sends  a  Request  to  the  service  host,  (2) 
the  service  host  returns  a  Reply  to  the  user  host,  and  (3)  the 
user  host  returns  a  Reply  Acknowledgment  to  the  service  host. 
This  procedure  is  used  to  insure  reliable  transmission  of 
requests  and  replies.  In  order  to  allow  more  than  one  setup 
request  message  from  a  host  to  be  outstanding,  each  request  is 
assigned  a  unique  Request  ID.  The  associated  Reply  and 
subsequent  Reply  Acknowledgment  are  identified  by  the  Request  ID 
that  they  contain.  Hosts  should  generally  expect  a  minimum  delay 
of  about  two  satellite  round-trip  times  between  the  transmission 
of  a  setup  Request  to  the  SIMP  and  the  receipt  of  the  associated 
Reply.  (Note  that  the  Join  Group  Request  and  the  Leave  Grovp 
Request  require  only  local  r.onanunicatlon  betuefen  a  host  and  Its 
SIMP.  The  response  time  for  these  requests,  therefore,  is 
dependent  solely  on  SIMP  processing  time  and  should  be 

considerably  shorter  than  two  round-trip  times.)  This  delay 
establishes  a  maximum  rate  at  which  changes  can  be  processed  by 
the  SIMP.  The  user  should  receive  a  reply  to  a  setup  request 
requiring  global  communication  within  2  seconds  and  to  a  setup 
request  requiring  local  commixnlcation  within  1  second.  The  host 
should  rn-rpond  tc  a  SIMP  Reply  with  a  Reply  /.cl<r.cwlcdg=cr.t 
1  second. 
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Setup  exchanges  caul  also  be  initiated  by  the  SIMP.  SIMP- 
initiated  setup  messages  are  used  to  notify  a  host  of  changes  in 
the  status  of  an  associated  group  or  stream.  Each  notification 
involves  a  2 -way  exchange  where:  (1)  the  service  host  sends  a 
Notification  to  the  user  host,  and  (2)  the  user  host  returns  a 
Notification  Acknowledgment  to  the  service  host.  In  order  to 
allow  more  than  one  Notification  to  be  outstanding,  each  is 
assigned  a  unique  Notification  ID.  The  Notification 
Acknowledgment  returned  by  the  user  host  to  the  service  host  must 
contain  the  Notification  ID. 

The  general  format  of  every  setup  message  is: 

<DATAGRAM  MESSAGE  KEADER> 

<OPTIONAL  INTERNET  HEADER> 

<SETUP  MESSAGE  HEADEP> 

<SETUP  MESSAGE  B0DY> 


The  service  host  accepts  setup  requests  in  either  Internet  or 
non- Internet  format.  Replies  from  the  service  host  will  be  in 
the  same  form  as  the  request,  tiiat  is,  Internet  requests  get 
Internet  replies,  and  non- Internet  requests  get  non- Internet 
replies. 


The  format  of  the  combined  datagram  message  header  and  setup 
isassage  header  is  illustrated  in  Figure  6.  The  bod^'  of  the  setup 
messages  depends  on  the  particular  setup  message  type.  Stream 
request  and  reply  messages  are  described  in  Section  6.1.  Group 


and  rv,ply 


Section  6.2. 


sinplify  the  presentation  in  both  of  these  sections,  the  setup 
messages  are  assumed  to  be  exchanged  between  a  local  hose  and 
SIMP  even  though  Internet  group  and  stream  setups  are  supported 
(see  Figure  6) .  The  format  of  notifications,  which  consists  of 
only  a  single  word  beyond  the  basic  setup  header,  is  sl’iown  in 
Figure  7.  Since  the  SIMP  does  not  retain  the  optional  Internet 
header  information  that  can  be  Included  in  setup  requests, 
Internet:  notifications  are  not  supported.  The  format  of 
acknowledgment  messages  associated  with  request/reply  and 
notification  setups  is  Illustrated  in  Figure  8. 
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Request  Type. 

1  =  Create  groqp  address 

2  -  Delete  groqp  address 

3  =  Join  groqp 

4  =  Leave  group 

5  =  Create  stream 

6  =  Delete  stream 

7  =  Change  stream  parameters 

8  =  Reserved 

For  Replies,  this  field  provides  the  Reply  Code.  Some 
of  the  Reply  Codes  can  be  returned  to  any  setup 
request  and  others  are  request  specific. 

0  =  Groip  or  stream  created 

1  =  Group  or  stream  deleted 

2  s  Groip  joined 

3  =  Group  left 

4  =  Stream  changed 

5  =  Reserved 

6  =  Bad  request  type 

7  =  Reserved 

8  =  Network  trouble 

9  =  Bad  key 

10  =  Group  address/stream  ID  nonexistent 

11  =  Not  member  of  group/creator  of  stream 

12  =  Stream  priority  not  being  accepted 
13=  Rf«iKArv««d 

14  =  Reserved 

15  =  Illegal  Interval 

16  =  Reserved 

17  =  Insufficient  network  resources 

18  -  Requested  bandwidth  too  large 

19  =  Reserved 

20  =  Reserved 

21  =  Maximum  messages  per  slot  not  consistent  with 

slot  size 

22  -  Reply  lost  in  network 

23  -  Illegal  reliability  value 
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For  Notifications,  this  field  contains  the 
Notification  Type. 

0  =  Stream  suspended 

1  -  Stream  resumed 

2  -  Stream  deleted 

3  =  Group  deleted  by  host 

4  =  Group  deleted  by  SIMP 

5  -  All  streams  deleted 

6  -  All  groups  deleted 

For  Admovledcpnents,  this  field  contains  the 
Acknovledgnent  T^pe. 

0  =  Rsply  acknowledgment 

1  =  Notification  acknowledgment 

N>2[0-15]  Setup  Checksuoa.  The  checksum  covers  the  three  setup 
message  header  words  and  the  set^p  message  body  data 
words.  Setups  received  with  bad  checksums  must  be 
discarded. 

N+3[0-15]  Setup  ID.  This  field  is  assigned  by  the  host  to 
uniquely  identify  outstanding  requests  (Request  ID) 
and  by  the  service  host  to  uniquely  identify 
outstanding  notifications  (Notification  ID) . 
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— 4.--+--+--+--+--+--+--+ 

I  DATAC3RAM  MESSAGE  HEADER  | 

4. -+--4.- -4.- — 4.- -4. --4.- -4.. -4. --4.- -4.. -4. 

I  3  I  NOTIFICATION  TYPE  | 

+  —  4.- -4.- -4.- -4.- -4.- -4. --4.- -4-- --f 

I  SETXJP  CHECKSUM  | 


NOTIFICATION  ID 


.4. --4.- -4. --4. --4.-.  4. 


I  NOTIFICATION  INFO  | 

4— -4-  —  4-- -  +  —  4— -  +  + 


Figure  7  .  NOTIFICATION  MESSAGE 


•5  Datagram  Message  Header  (see  Section  3)  . 

6  [8-15]  Setup  Type  *  3  (Notification)  . 

6  [0-7]  Notification  TVP®* 

0  s  Stream  suspended 

1  »  Stream  resumed 

2  =  Stream  deleted 

3  s  Group  deleted  by  host 

4  ~  Croup  deletcKl  by  SIMP 

5  -  All  streams  deleted 

6  s  All  groups  deleted 

7 [0-15]  Setup  Checksum.  Covers  words  6-9. 

8 [0-15]  Notification  ID. 

9 [0-15]  Notification  Information.  This  field  contains  the 

16-bit  group  address  in  the  case  of  a  group 
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notification  (types  3  and  4)  and  the  10 -bit  host 
stream  ID  (ri^t  justified)  in  the  case  of  a  stream 
notification  (types  0-2) .  This  field  is  zero  for 
Notification  Types  5  and  6,  whicli  pertain  to  ALL 
streams  and  groups,  respectively. 
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6.1  Stream  Setup  Messages 

Hosts  use  streams  to  support  higji  duty  cycle  applications 
and  applications  requiring  a  one  satellite  hop  network 
transmission  delay.  Host  streams  must  be  set  up  before  stream 
data  messages  can  flow.  The  stream  setup  messages  defined  by  HAP 
are  Create  Stream  Request,  Create  Stream  Reply,  Delete  Stream 
Request,  Delete  Stream  Reply,  Change  Stream  Parameters  Request, 
and  Change  Stream  Parameters  Reply.  The  use  of  these  messages  is 
illustrated  in  the  scenario  of  exchanges  between  a  host  and  its 
local  SIMP  shown  in  Figure  9  where  the  host  establishes  a  stream, 
sends  some  data,  modifies  the  stream  characteristics,  sends  some 
more  data,  and  finally  closes  down  the  stream. 

It  is  worthwhile  noting  that  the  setup  exchanges  in  Figure  9 
are  conpletely  between  the  host  originating  the  stream  and  its 
local  SIMP.  Other  SIMPs  and  hosts  are  essentially  unaware  of  the 
existence  of  the  stream.  Stream  messages  received  hy  a 
destination  host  are,  therefore,  processed  Identically  to 
datagram  messages.  (All  SIMPs  must,  of  course,  be  aware  of  the 
channel  allocation  associated  with  a  host  stream  in  order  to 
perform  satellite  channel  scheduling.)  Not  illustrated,  but 
implicit  in  this  scenario,  are  the  optional  A/R  Indications 
associated  with  each  of  the  stream  setup  messages. 
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Host  SIMP 


Create  Stream  Request  > 

Create  Stream  Reply  < - 

Reply  Acknowledgment  > 

Stream  Message  > 


Stream  Message  > 

Change  Stream  Parameters  Request  - > 

Change  Stream  Parameters  Rqply  < - 

Reply  Acknowl  edgment  > 

Stream  Message  > 


Stream  Message  - > 

Delete  Stream  Request  ’  - > 

Delete  Stream  Reply  < - 

Reply  Acknowledgment  - > 


Figure  9  ,  STREAM  EXAMPLE 


Host  streams  have  six  characteristic  properties  which  are 
selected  at  stream  setup  time.  These  properties,  which  apply  to 
every  message  transmitted  in  the  stream,  are:  (1)  slot  size,  (2) 
Interval,  (3)  reliability,  (4)  reliability  length,  (5)  priority, 
and  (6)  maximum  messages  per  slot.  To  establish  a  stream,  the 
host  sends  the  Create  Stream  Request  message  Illustrated  in 
Figiire  10  to  the  SIMP.  After  the  satellite  network  has  processed 
the  Create  Stream  Request,  the  SIMP  will  respond  to  the  host  with 
a  Create  Stream  Reply  message  formatted  as  shown  in  Figv.ire  11. 
Assuming  that  the  reply  code  in  the  Create  Stream  Reply  is  zero 
indicating  that  the  stream  has  been  created  successfully,  the 
host  may  proceed  to  transmit  stream  data  messages  after  sending  a 
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^  Reply  Acknowledgment . 

\  During  the  lifetime  of  a  stream,  the  host  which  created  it 

\  may  decide  that  some  of  its  six  characteristic  properties  should 

be  modified.  All  of  the  properties  except  the  stream  Interval 
cai\  be  modified  using  the  Change  Stream  Parameters  Request 
message.  Ihe  format  of  this  conmand  is  illustrated  in  Figure  12. 
After  the  network  has  processed  the  Change  Stream  Parameters 
Request,  the  SIMP  will  respond  by  sending  a  Change  Stream 
Parameters  Reply  to  the  host  with  the  format  shown  in  Figure  13. 
A  host  requesting  a  reduced  channel  allocation  should  decrease 
its  sending  rate  Ixnnedlately  without  waiting  for  receipt  of  the 
Change  Stream  Parameters  Reply.  A  host  requesting  an  increased 
allocation  should  not  proceed  to  trarismit  according  to  the  new 
set  of  parameters  without  first  having  received  a  Reply  Code  of  4 
indicating  that  the  requested  change  has  taken  effect. 

When  the  host  which  created  the  host  stream  determines  that 
the  stream  is  no  longer  needed  and  the  associated  satellite 
channel  allocation  can  be  freed  up,  the  host  sends  its  local  SIMP 
I  a  Delete  Stream  Request  message  formatted  as  indicated  in  Figure 

14.  After  the  network  has  processed  the  Delete  Stream  Request, 

I  the  SIMP  will  respond  by  sending  a  Delete  Stream  Reply  to  the 

i  host  with  the  format  shown  in  Figure  15. 
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Figure  10  .  CREATE  STREAM  REQUEST 


0-5 

6  [8-15] 
6[0-7] 

7 [0-15] 
8  [0-15] 


Datagram  Message  Header. 

Setup  Type  =  1  (Request)  . 

Reqiest  Type  =  5  (Create  Stream) . 
Setup  Checksum.  Covers  words  6-10. 
Request  ID. 


9 [12-15]  Maximum  Messages  Per  Slot.  This  field  sp>eclfies  the 
the  maximum  number  of  stream  messages  that  will  ever 
be  delivered  to  the  SIMP  by  the  host  for  transmission 
in  one  stream  slot. 


9  [10-11]  Interval.  This  field  specifies  the  interval,  in 
number  of  21.2  ms  frames,  between  stream  slots. 
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9  [8-9] 


9  [6-7] 


9  [0-5] 


10  [0-15] 


0=1  frame 
1=2  frames 
2=4  frames 
3=8  frames 

As  an  exanple,  an  interval  of  4  frames  corresponds  to 
an  allocation  of  Slot  Size  words  every  85  ms. 

Priority.  This  field  specifies  the  priority  at  which 
all  messages  in  the  host  stream  should  be  handled. 

0  =  Low  priority 

1  =  Medium  Low  Priority 

2  =  Medium  High  Priority 

3  =  Hi^n  Priority 

Reliability.  This  field  specifies  the  basic  bit¬ 
error  rate  requirement  for  the  data  portion  of  all 
messages  in  the  host  stream. 

0  =  Low  Reliability 

1  =  Medium  Reliability 

2  =  Hi^  Reliability 

3  =  Reserved 

Reliability  Length.  This  field  sp€K:ifies  how  many 
words  beyond  the  stream  message  header  should  be 
transmitted  at  maximum  reliabilit*/  for  all  messages 
in  the  host  stream. 

Slot  Size.  This  field  specifies  the  slot  size  in 
16-bit  words  of  stream  message  text.  Stream  message 
header  words  are  excluded  from  tixis  count.  The  host 
can  partition  this  allocation  on  a  slot-by-slot  basis 
among  a  variable  number  of  messages  as  long  as  the 
maximum  number  of  messages  per  slot  does  not  exceed 
MAX  MES, 
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0-5  I  DATAGRAM  MESSAGE  HEADER  | 

6  I  2  1  REPLY  CODE  | 

7  I  SETUP  CHECKSUM  | 

4--4 --4- -4.- -4-- + 

8  -  i  REQUEST  ID  | 

4__  4- _  4- -4--4-_4_-4--4--4--4--4---f--  +  --f- -  + 

9  I  XXXXX  I  HOST  STREAM  ID  | 

4__4__4__4__4_-4-_4--4--4--4--4»-4--4--4---f---f---f 

Figure  11  .  CREATE  S'rREAM  REPLY 


0-5 

6 [8-15] 
6[0-7] 


7[0-15] 


Datagram  Message  Header. 

Setup  Type  =  2  (Reply)  . 

Reply  Code. 

0  =  Stream  created 
8  =  Network  trouble 

12  =  Stream  priority  not  being  accepted 

17  =  Insufficient  network  resources 

18  =  Requested  bandwidth  too  large 

21  -  Maximum  messages  per  slot  not  consistent 

with  slot  size 

22  =  Reply  lost  in  network 

23  =  Illegal  reliability  value 

Setup  Checksum.  Covers  words  6-9. 


8  [0-15]  Request  ID. 
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9  [10-15]  Reservcsci. 

9 [0-9]  Host  Stream  ID.  This  field  contains  a  host  stream 
ID  assigned  by  the  network.  It  must  be  included  in 
all  stream  data  messages  sent  by  the  host  to  allow 
the  SIMP  to  associate  the  message  with  stored  stream 
characteristics  and  the  reserved  satellite  channel 
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Figure  12  .  CHANCE  STREAM  PARAMETERS  REQUEST 


5 

Datagram  Message  Header. 

6 [8-15] 

Setup  Type  =  1  (Request)  . 

6[0-7] 

Request  Type  =  7  (Change  Stream  Parameters)  . 

7 [0-15] 

Setup  Checksum.  Covers  words  6-11. 

8 [0-15] 

Request  ID. 

9[10-15] 

Reserved. 

9[0-9] 

Host  Stream  ID. 

10  [12-15]  New  Maximm  Messages  Per  Slot. 
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10  [10-11] 

Interval.  This  field  must  specifiy  the  same 
interval  as  was  specified  in  the  Create  Stream 
Request  message  for  this  stream. 

10  [8-9] 

New  Priority. 

10  [6-7] 

New  Reliability. 

10  [0-5] 

New  Reliability  Length. 

11  [0-15] 

New  Slot  Size. 
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I  DATAGRAM  MESSAGE  HEADER  I 


REPLY  CODE 


I  SETUP  CHECKSUM  | 

I  REQUEST  ID  | 


Figure  13  .  CHANGE  STREAM  PARAMETERS  REPLY 


'5  Datagram  Message  Header. 

6  [8-15]  Setup  Type  =  2  (R^ly)  . 

6 [0-7]  Reply  Code. 

4  »  Stream  changed 
8  =  Network  trouble 

10  =  Stream  ID  nonexistent 

11  =  Not  creator  of  streiua 

12  -  Stream  priority  not  being  accepted 
15  =  Illegal  interval 

17  =  Insufficient  network  resources 

18  =  Requestcxl  bandwidth  too  large 

21  =  Maximum  messages  per  slot  not  consistent  with 

slot  size 

22  =  Reply  lost  in  network 

23  =  Illegal  reliability  value 

7 [0-15]  Setup  Checksum.  Covers  words  6-8. 

8ro-15]  Request  ID. 
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0*5  I  DATAGRAM  MESSAGE  HEADER  | 

6  I  2  I  REPLY  CODE  | 

7  I  SETUP  CHECKSUM  | 

4--4--4-^4.-4--4--4--4_-4-.4_-4--4--4--4--4--4--4 
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Figure  15  .  DELETE  STREAM  REPLY 


0*5  Datagraa  Message  Header. 

6 [8-15]  Setup  Type  *  2  (Reply). 

6 [0-7]  Reply  Code. 

1  s  Stream  deleted 
8  «  Network  trouble 

10  s  Stream  ID  none>i stent 

11  s  Hot  creator  c£  stream 

17  =  Insufficient  network  resources 
22  =  Reply  lost  in  network 

7  [0-15]  Setup  Checksum.  Covers  words  6-8. 

8[0-15]  Request  ID. 


43 


«77 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1985 


RFC  907  Host  Access  Protocol 

July  1984  Spec! f ication 


6.2  Grouqp  Setup  Messages 

Group  addressing  allows  hosts  to  take  advantage  of  the 
broadcast  capability  of  th«  satellite  network  and  is  primarily 
provided  to  support  the  multi -destination  aelivery  required  for 
conferencing  applications.  Group  addresses  are  dynamically 
created  and  deleted  via  setup  messages  exchanged  between  hosts 
and  the  network.  Membership  in  a  group  may  consist  of  an 
arbitrary  subset  of  all  the  permanent  network  hosts.  A  datagram 
message  or  stream  message  addressed  to  a  group  is  always  sent 
over  the  satellite  channel  and  delivered  to  all  hosts  that  are 
members  of  that  group.  The  group  setup  messages  are  Create  Group 
Request,  Create  Group  Reply,  Delete  Group  Request,  Delete  Grovp 
Reply,  Join  Group  Request,  Join  Group  Reply,  Leave  Group  Request, 
and  Leave  Group  Reply. 

The  use  of  group  setup  messages  is  shown  in  Figure  16.  The 
figure  illustrates  a  scenario  of  exchanges  betwecii  two  h,osts  and 
their  local  SIMPs.  In  the  scenario  one  host.  Host  A,  creates  a 
group  which  is  joined  by  a  second  host.  Host  B.  After  the  two 
hosts  have  exchanged  some  data  mesages  addressed  to  the  group. 
Host  B  decides  to  leave  the  group  and  Host  A  decides  to  delete 
the  group.  As  in  the  scenario  in  Section  6.1,  A/R  indications 
have  been  omitted  for  clarity. 

Part  of  the  group  creation  procedure  involves  the  service 
host  returning  a  48 -bit  key  along  with  a  16 -bit  group  address  to 
the  host  creating  the  group.  The  creating  host  must  pass  the  key 
along  with  the  group  address  to  the  other  hosts  which  it  wants  as 
group  members.  Those  other  hosts  must  supply  the  key  along  with 
the  group  address  in  their  Join  Group  Requests.  The  key  is  used 
by  the  network  to  authenticate  these  operations  and  thereby 
minimize  the  probability  that  unwanted  hosts  will  deliberately  or 
inadvertently  become  members  of  the  group.  The  proct:jdure  used  by 
a  host  to  distribute  the  group  address  and  key  is  not  within  the 
scope  of  HAP. 
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Host  SIMP  SIMP  Host 
A  A  B  B 

Create  Group  Request  > 

Create  Grovp  Reply  < - - 

Reply  Aclonowledgment  > 


»Groijqp  Address,  Key» 


Join  Group  Request  < - 

Join  Group  Reply  - > 

Reply  Aclonowledgment  <' - 

Data  Message  1  > 

Data  Message  1  < -  > 

Data  Message  2  < - 

Data  Message  2  < -  > 

Leave  Grov^j  Rciquest  < - 

Leave  Group  Reply  - > 

Reply  Acknowledgnient  < - 

Delete  Group  Request  > 

Delete  Group  Reply  < - 

Reply  Aclonowledgooent  > 


Figure  16  .  GROUP  EXAMPLE 


Any  host  no  longer  wishing  to  participate  In  a  group  may 
choose  to  drop  out.  This  can  be  acconpllshed  by  either  a  Leave 
or  a  Delete.  Both  Leave  and  Delete  operations  are  authenticated 
using  the  48-blt  key.  Leave  Is  a  local  operation  between  a  host 
and  its  SIMP  which  removes  the  requesting  host  from  the  group 
membership  list  but  does  not  alter  the  global  existence  of  the 
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group.  A  Delete^  on  the  other  hand,  ejqjunges  all  knowledge  of 
the  group  from  every  SIMP  in  the  network.  HAP  will  permit  any 
member  of  a  group  to  delete  the  group  at  any  time.  Thus,  group 
addresses  can  be  deleted  even  if  the  host  which  originally 
created  the  group  has  left  the  group  or  has  crashed.  Moreover, 
groups  may  exist  for  which  there  are  currently  no  members  because 
each  member  has  executed  a  Leave  while  none  has  executed  a 
Delete.  It  is  tlie  responsibility  of  the  hosts  to  coordinate  and 
manage  the  use  of  groups. 

The  Create  Group  Request  message  sent  to  the  service  host  to 
establish  a  group  address  is  illustrated  in  Figure  17.  After  the 
network  has  processed  tiie  Create  Group  Request,  the  service  host 
will  respond  by  sending  a  Create  Group  R^ly  to  the  host  as 
illustrated  in  Figure  18. 

A  host  may  become  a  member  of  a  group  once  it  knows  tlie 
address  and  key  associated  with  the  group  by  sending  the  service 
host  the  Join  Group  Request  message  shown  in  Figure  19.  The 
service  host  will  respond  to  the  Join  Group  Request  with  a  Join 
Group  Reply  formatted  as  indicated  in  Figure  20.  The  host  which 
creates  a  group  automatically  becomes  a  member  of  that  group 
without  any  need  for  an  explicit  Join  Grojp  Request. 

At  any  time  after  becoming  a  member  of  a  group,  a  host  may 
choose  to  drop  out  of  the  group.  To  effect  this  the  host  sends 
the  service  host  a  Leave  Group  Request  formatted  as  shown  in 
Figure  21.  The  service  host  will  respond  to  the  Leave  Group 
Request  with  a  Leave  Group  Reply  formatted  as  snown  in  Figure  22. 

Any  member  of  a  group  can  request  that  the  service  host 
delete  an  existing  group  via  a  Delete  Group  Request.  The  format 
of  the  Delete  Group  Request  setup  message  is  illustrated  in 
Figure  23.  After  the  network  has  processed  the  Delete  Group 
Request,  the  service  host  will  respond  to  the  host  with  a  Delete 
Group  Reply  formatted  as  illustrated  in  Figure  24. 
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Figure  18  .  CREATE  GROUP  REPLY 


0-5  Datagram  Message  Header. 

6  [8-15]  Setup  Type  =  2  (Reply)  . 

6 [0-7]  Reply  Code. 


0  =  Group  created 
8  =  Network  trouble 
17  =  Insufficient  network  resources 
22  =  Reply  lost  in  network 

7  [0-15]  Setup  Checksum.  Covers  words  6-12. 


8 [0-15]  Request  ID. 
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I  DATAGRAM  MESSAGE  HEADER  | 

I  1  i  1  I 

I  SETUP  CHECKSUM  | 

1  REQUEST  ID  j 


Figure  17  .  CREATE  C310UP  REQUEST 


0-5 

6 [8 '15] 
6 [0-7] 

7 [0-15] 
8 [0-15] 


Datagram  Message  Header. 

Setup  Type  =  1  (Request)  . 

Request  Type  ss  1  (Create  Group)  . 
Setup  Checksum.  Covers  words  6-8. 
Request  ID. 
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9[0-15J  Group  Address.  This  field  contains  a  16 -bit  logical 
address  assigned  by  the  network  \rtiich  may  be  used  by 
the  host  as  a  group  address. 

Key.  This  field  contains  a  48-bit  key  assigned  by  the 
network  which  is  associated  with  the  group  address. 
It  must  be  provided  for  subsequent  Join,  Leave,  and 
Delete  requests  which  reference  the  group  address. 
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0-5  I  DATAGRAM  MESSAGE  HEADEF  i 

6  I  2  1  REPLY  CODE  | 
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8  I  REQUEST  ID  | 

— + — 4--+--+--+ — 

Figure  20  .  JOIN  GROUP  REPLY 
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0-5  Datagram  Message  Header. 

6  [8-15]  Setup  Type  =  2  (Reply)  . 

6 [0-7]  Reply  Code. 


2  =  Groijp  joined 
9  -  Bad  key 

10  -  Groijp  address  nonexistent 
17  =  Insufficient  network  resources 

7 [0-15]  Setijp  Checksum.  Covers  words  6-8. 


8 [1-15]  Request  ID. 
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Figure  21  .  LEAVE  GROUP  REQUEST 


0-5 

6  [8-15] 

6ro-7] 

'[0-15] 

8[0-15] 

9[0-15] 

10-12 


Datagram  Message  Header. 

Setup  Type  =  1  (Request) . 

Request  Typo  =  4  (Leave  Croup) . 

Setup  Checksum.  Covers  words  6-12. 

Request  ID. 

Group  Address.  This  is  the  logical  address  of  the 
group  that  the  l.ost  wishes  to  leave. 

Key.  This  is  tne  key  associated  with  the  group 
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7  Link  Monitoring 

While  the  acc€»s  link  is  operating,  statistics  on  traffic 
load  and  error  rate  are  ffiaintainud  by  the  host  arxi  SIMP.  The 
host  and  SIMP  must  exchange  status  messages  once  a  second. 
Periodic  exchange  of  status  messages  permits  both  ends  of  the 
link  to  monitor  flows  in  both  directions.  Status  messages  are 
required  to  suqpport  monitoring  by  the  Network  Operations  Center 
(HOC)  . 

The  link  restart  procedure  (see  Section  8)  initializes  all 
internal  SIMP  counts  and  statistics  for  that  link  to  zero.  As 
data  and  control  messages  are  processed,  counts  are  updated  to 
reflect  the  total  number  of  messages  sent,  messages  received 
correctly,  and  messages  received  with  different  classes  of  errors 
since  the  last  link  restart.  Whenever  a  status  message  arrives, 
a  snapshot  is  taken  of  the  local  SIMP  counts.  The  local  receive 
counts,  in  conjunctlcxi  with  a  sent  count  contained  in  thai 
rcK:eived  statiis  message,  permits  the  cooputation  of  traffic 
statistics  in  the  one  second  update  interval  assuming  that  the 
set  of  cour/wS  at  the  time  of  the  previous  monitoring  report  have 
been  saved.  By  including  in  the  status  message  sent  (in  the 
opposite  direction)  the  receive  counts  and  the  received  sent 
count  that  was  used  with  them,  the  transmitting  end  of  the  access 
link  as  well  as  the  receiving  end  can  determine  the  link 
performance  from  sexier  to  receiver.  The  format  of  the  Status 
control  message  is  illustrated  in  Figure  25. 
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Figure  23  .  DELETE  C210UP  REQUEST 
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Datagram  Message  Header. 

6 [8-15] 

Setup  Type  »  1 

(Request)  . 

6[0-7] 

Request  TVP^  ^ 

2  (Delete  Croup) . 

7[0-15] 

Setup  Checksum. 

Covers  words  6- 

8 [0-15] 

Request  ZD. 

9[0-15] 

Croup  Address. 
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0-5  I  DATAGRAM  MESSAGE  HEADER  | 

6  I  2  I  REPLY  CODE  1 

7  I  SETUP  CHECKSUM  | 

8  j  REQUEST  ID  [ 


Figure  22  .  LEAVE  GROUP  REPLY 


C'5  Datagram  Message  Header. 

6  [8-15]  Setuqp  Type  =  2  (Reply)  . 

6 [0-7]  Reply  Code. 

3  =  Group  left 
9  =  Bad  key 

10  =  Group  address  nonexistent 

11  =  Not  member  of  group 

17  =  Insufficient  network  resources 


7  [0-15]  Setup  Checksum.  Covers  words  6-8. 
8 [0-15]  Request  ID. 
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Figure  25  ,  STATUS  MESSAGE 
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Go-Priority. 
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Control  Message  Type  =  0  (Status) . 

Header  Checksum.  Covers  words  0-10. 

Most  Recent  A/R  Sent.  This  field  is  a  duplicate  of  the 
most  recent  acceptance/refusal  word.  It  is  included  in 
the  periodic  status  message  in  case  previous 
transmissions  containing  A/R  information  were  lost. 

Stream  Capacity.  When  sent  by  the  SIMP,  this  field 
indicates  how  much  stream  capacity  is  unused,  in  units 
of  data  bits  per  frame.  Since  available  capacity 
depends  directly  on  a  variety  of  parameters  that  can  be 
selected  by  the  user,  the  value  of  this  field  is  the 
maximum  capacity  that  could  be  achieved  if  existing 
host  streams  were  oqjanded  at  low  reliability.  This 
field  is  undefined  in  messages  sent  from  the  host  to 
the  SIMP. 

Timestanp.  This  field  Indicates  the  time  that  the 
status  message  was  generated.  When  sent  by  a  SIMP,  the 
time  is  in  units  of  seconds  since  the  last  link 
restart.  The  host  should  also  timestanp  its  messages 
in  units  of  seconds. 

Sent  By  Us.  Count  of  messages  sent  by  us  since  the  last 
link  restart  (not  including  this  one) . 

Sent  To  Us.  Count  of  messages  sent  to  us  since  the 
last  link  restart.  This  is  the  count  from  word  5  of 
the  last  status  message  received. 

Received,  No  Errors.  This  is  the  count  of  messages 
received  without  errors  (since  the  last  link  restart) 
at  the  time  that  the  last  status  message  was  received. 

Received  With  Errors.  This  is  the  count  of  messages 
received  with  errors  (since  the  last  link  restart)  at 
the  time  the  last  status  message  was  received. 

Bad  Header  Checksums.  This  is  the  count  of  messages 
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received  with  bad  header  checksums  (since  the  last  link 
restart)  at  the  time  the  last  status  message  was 
received . 

10  [0-15]  Hardware  Error  Indication.  This  Is  the  count  of 
messages  received  with  hardware  CRC  errors  or  hardware 
Interface  error  Indications  (since  the  last  link 
restart)  at  the  time  the  last  status  message  was 
received. 
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6  Initialization 

The  Host  Access  Protocol  uses  a  number  of  state  variables 
that  must  be  initialized  in  order  to  function  properly.  These 
variables  are  associated  with  the  send  and  receive  message 
numbers  used  by  the  acceptance/refusal  mechanism  and  the 
statistics  maintained  to  support  link  monitoring.  Link 
initialization  should  be  carried  out  when  a  machine  is  initially 
powered  up,  when  it  does  a  syst  am  restart,  when  the  ON  state  (see 
below)  times  out,  when  a  loopback  condition  times  out  (see 
Section  9) ,  or  whenever  the  link  transitions  from  non-operational 
to  operational  status. 

Initialization  is  accomplished  by  the  exchange  of  Restart 
Request  (RR)  and  Restart  Complete  (RC)  messages  between  a  host 
and  a  SIMP.  The  state  diagram  in  Figure  26  shows  the  sequence  of 
events  during  initialization.  Both  SIMP  and  host  must  iiplement 
this  state  diagram  if  deadlocks  and  oscillations  are  to  be 
xvoiHaH  This  particular  Initialization  sequence  requires  both 
sides  to  send  and  receive  the  Restart  Conplete  message.  Because 
thi!?:  message  is  a  reply  (to  a  Restart  Request  or  Restart 
Complete) ,  its  receipt  guarantees  that  the  physical  link  is 
operating  in  both  directions.  Five  states  are  identified  in  the 
state  diagram: 

OFF  Entered  upon  recognition  of  a  requirement  to 

restart.  The  device  can  recognize  this 

requirement  itself  or  be  forced  to  restart  by 
receipt  of  an  RR  message  from  the  other  end  while 
in  the  ON  state. 

INIT  Local  state  variables  have  been  initialized  and 

local  counters  have  been  zeroed  but  no  restart 
control  messages  have  yet  been  sent  or  received. 

RR-SNT  A  request  to  reinitialize  (RR)  has  been  sent  to 

the  other  end  but  no  restart  control  messages  have 
yet  been  received. 

RC'SNT  A  reply  (RC)  has  been  sent  to  the  other  end  in 

response  to  a  receivcxl  reinitialization  request 
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Figure  26  .  HAP  LINK  RESTART  STATE  DIAGRAM 
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Figure  27  .  RESTART  REQUEST 


0 [15]  Message  Type  -  1  (Control  Message) ; 

0[14]  Loopback  Bit. 

0 [8- 1 3]  Reserved . 

0[4-7]  Reason,  lliis  field  is  used  by  the  SIMP  or  the  host  to 
indicate  the  reason  for  the  restart  as  follows: 


0  =  power  up 

1  =  system  restart 

2  =  link  restart 

3  =  link  timeout 

4  =  loopback  timeout 

0[0-3]  Control  Message  Type  =  3  (R»  start  Request) . 

1[0-15]  Header  Checksum.  Covers  words  0-3. 

2 [0-15]  Host  Address  /  Site  Number.  The  host  inserts  its 
satellite  network  address  in  this  field.  The  SIMP 
validates  that  the  host  address  is  correct  for  the  port 
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being  used.  When  sent  by  the  SIMP,  this  field  will 
contain  the  SIMP  site  number. 

3  [0-15]  Link  Number.  This  field  contains  the  sender's 
identification  of  the  physical  link  being  used.  This 
information  is  used  to  identify  the  link  when  reporting 
errors  to  the  Network  Operations  Center  (NOC) . 
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The  Host  Access  Protocol  provides  a  Loopback  Request  control 
message  which  can  be  used  by  a  SIMP  or  a  host  to  request  the 
remote  loopback  of  its  KAP  messages.  Such  requests  are  usually 
the  result  of  operator  intervention  for  purposes  of  system  fault 
diagnosis.  For  clarity  in  the  following  discussion^  the  unit 
(SIMP  or  host)  requesting  the  remote  loopback  is  referred  to  as 
the  "transmitter'*  and  the  unit  laplementing  (or  rejecting)  the 
loopback  is  referred  to  as  the  "receiver**.  The  format  of  a 
Loopback  Request  control  message  is  illustrated  in  Figure  29. 


When  a  transmitter  is  remotely  looped,  all  of  its  KAP 
messages  will  be  returned,  unmodified,  over  the  access  link  by 
the  receiver.  The  receiver  will  not  send  any  of  its  own  messages 
to  the  transmitter  while  it  is  iaplementing  the  loc^.  SIMP- 
generated  messages  are  distinguished  from  host -generated  messages 
means  of  the  Loopback  Bit  that  is  in  every  HAP  message  header. 


Two  types  of  remote  loopback  may  be  requested:  loopback  at 
the  receiver's  interface  hardware  and  loopback  at  the  receiver's 
I/O  driver  software.  KAP  does  not  specify  the  manner  in  which 
the  receiver  should  ioplemant  these  loops;  additionally,  some 
receivers  may  use  interface  hardware  which  is  incapable  of 
looping  the  transmitter's  messages,  only  allowing  the  receiver  to 
provide  software  loops.  A  receiver  may  not  be  able  to  interpret 
the  transmitter's  messages  as  it  is  looping  them  back.  If  such 
interpretation  is  possible,  however,  the  receiver  will  not  act  on 
any  of  the  transmitter's  messages  other  than  requests  to 
reinitialize  the  SIMP-host  link  (RMtart  Request  (RR)  control 
messages;  see  Section  8.) 


When  a  receiver  initiates  a  loofi^ck  condition  in  response 
to  a  loopback  request,  it  makes  an  isplicit  promise  to  maintain 
the  condition  for  the  duration  iq>ecified  in  the  Loopback  Request 
message.  However,  if  an  unanticipated  condition  such  as  a  system 
restart  occurs  in  either  the  transmitter  or  the  receiver,  the 
affected  unit  will  try  to  reinitialize  the  SIMP -host  link  by 
sending  an  RR  message  to  the  other  unit.  If  the  RR  message  is 
recognized  by  the  other  unit  a  link  initialization  sequence  can 
be  completed.  This  will  restore  the  link  to  an  unlooped 
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condition  even  if  the  specified  loop  duration  has  not  yet 
expired.  If  a  receiver  cannot  interpret  a  transmitter's  RR 
messages,  and  in  the  absence  of  operator  intervention  at  the 
receiver,  the  loop  will  remain  in  place  for  its  duration. 

HAP  does  not  specify  the  characteristics  of  any  loopback 
conditions  that  may  be  locally  inplemented  by  a  given  unit.  An 
exanple  of  such  a  condition  is  that  obtained  %fhen  a  SIMP  comnands 
its  host  interface  to  loop  back  its  own  messages.  If  such  local 
loop  conditions  also  cause  the  reflection  of  messages  received 
from  the  remote  unit,  the  resaote  unit  will  detect  the  condition 
via  the  HAP  header  Loo^ack  Bit. 

A  specific  sequence  must  be  followed  for  setting  up  a  remote 
loopback  condition.  It  begins  after  the  HAP  link  has  been 
initialized  and  a  decision  is  made  to  requef;t  a  remote  loop.  The 
transmitter  then  sends  a  Loopback  Request  message  to  the  receiver 
and  waits  for  either  (1)  a  10-second  timer  to  expire,  (2)  a 
"Can't  iaplement  loop"  Unnumbered  Re^x>nse  message  from  the 
receiver,  or  (3)  one  of  its  own  reflected  messages.  If  event  (1) 
or  (2)  occurs  the  request  has  failed  and  the  transmitter  may,  at 
its  option,  try  again  with  a  new  Loopback  Request  message.  If 
event  (3)  occurs,  the  remote  loopback  condition  has  been 
established.  While  waiting  for  one  of  these  events,  messages 
from  the  receiver  are  processed  normally.  Note  that  RR  messages 
arriving  from  the  receiver  during  this  time  will  terminate  the 
loopback  request. 

When  a  receiver  gets  a  Loopback  Request  message,  it  either 
irplements  the  requested  loop  for  the  specificxl  duration,  or 
returns  a  "Can't  isplement  loop^'  response  without  changing  the 
state  of  the  link.  The  latter  response  would  be  returned,  for 
example,  if  a  receiver  is  incapable  of  isplementing  a  requested 
hardware  loop.  A  receiver  should  initiate  reinitialization  of 
the  link  with  an  RR  message (s)  whenever  a  loopback  condition 
times  out. 

There  Is  one  asymmetry  that  is  required  in  the  above 
aiequence  to  resolve  the  (unlikely)  case  where  both  SIMP  and  host 
request  a  remote  loopback  at  the  same  time.  If  a  SIMP  receives  a 
Lc<pback  Request  message  from  a  host  while  it  is  itself  waiting 


69 


^•703 


DDN  PROTOC'^i-  HANDBOOK  -  VOLUME  THREE 


1985 


RFC  907  Ho*t  Access  Protocol 

July  1984  %>ecific«tion 


for  an  event  of  typo  (l)-(3).  It  will  return  a  "Can't  laopleoent 
loop"  response  to  the  host  and  will  continue  to  wait.  A  host  in 
the  converse  situation,  however,  will  abort  its  loopback  request 
and  will  insr.ead  act  on  the  SIMP's  loopback  request. 
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Figure  29  .  LOOPBACK  REQUEST 


0[15]  Message  Type  ~  1  (Control  Message)  . 

0[14]  Loopback  Bit. 

0 [12-13]  Go-Prlorlfy. 

0[8-ll]  Reserved. 

0[4-7]  Loop  Type.  Ibis  field  Indicates  the  type  of  loop  that 
Is  being  requested  as  follows: 

0  s  Undefined 

1  s  Loop  at  Interface  (hardware  loop) 

2  »  Loop  at  driver  (software  loop) 

3-15  «  Undefined 


0[0-3]  Control  Message  Type  *  8  (Loopback  Request)  . 

1[0-15]  Header  Checksum.  Covers  words  0-2. 

2  [0-15]  Loop  Duration.  The  transmitter  of  a  Loopback 

Request  message  uses  this  field  to  pacify  the  number 
of  seconds  that  the  loop  Is  to  be  maintained  by  the 
receiver . 
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10  Other  Control  Messages 

Before  a  SIMP  or  a  host  voluntarily  disables  a  SIMP-host 
link,  it  should  send  at  least  one  Link  Going  Down  control  message 
over  that  link-  The  format  of  such  a  message  is  illustrated  in 
Figure  30.  HAP  does  not  define  the  action  (s)  that  should  be 
taken  by  a  SIMP  or  a  host  when  such  a  message  is  received; 
informing  the  Network  Operations  Center  (NOC)  and/or  the  network 
users  of  the  impending  event  is  a  typical  course  of  action.  Note 
that  each  Link  Going  Down  message  only  pertains  to  the  SIMP-host 
link  that  it  is  sent  over;  if  a  host  and  a  SIMP  are  connected  by 
multiple  links,  these  links  may  be  selectively  disabled. 

A  No  Operation  (NOP)  control  message  may  be  sent  at  any  tine 
by  a  SIMP  or  a  host.  The  format  of  such  a  message  is  illustrated 
in  Figure  31.  A  NOP  message  contains  up  to  32  words  of  arbitrary 
data  which  are  undefined  by  HAP.  NOP  messages  may  be  required  in 
some  cases  to  clear  the  state  of  the  SIMP-host  link  hardware. 
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Figure  30  .  LINK  GOING  DOWN 


0  [15]  Message  Type  =  1  (Control  Message)'. 

0[14]  Loopback  Bit. 

0  [12-13]  Go-Priority. 

0[8-ll]  Reserved. 

0[4-7]  Reason.  TMs  field  is  used  by  the  SIMP  or  the  host 
to  indicate  the  reason  for  disabling  this  SIMP -host 
link  as  follows: 


0  =  NOT  going  down:  Cancel  previous  Link 
Going  Down  message 

1  =  Unspecified  reason 

2  =  Scheduled  PM 

3  =  Scheduled  hardware  work 

4  =  Scheduled  software  work 

5  =  Emergency  restart 

6  =  Power  outage 

7  =  Software  breakpoint 

8  =  Hardware  failure 
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9  =  Not  scheduled  up 

10  =  Last  warning:  The  SIMP  or  host  is  disabling 
the  link  in  10  seconds 
11-15  =  Undefined 

Control  Message  Type  =  7  (Link  Going  Down)  . 

Header  Checksum.  Covers  words  0-3. 

Time  Until  Down.  This  field  specifies  the  amount  of 
time  remaining  until  the  SIMP  or  host  disables  the 
link  (in  minutes)  .  An  entry  of  zero  Indicates  that 
there  is  less  than  a  minute  remaining. 

Down  Duration.  This  field  specifies  the  amount  of 
time  that  the  SIMP-host  link  will  bo  down  (in 
minutes)  .  An  entry  of  zero  indicates  that  the  down 
duration  will  bo  less  than  a  minute.  An  entry  of  -1 
(all  bits  sat)  Indicates  an  indefinite  down  duration. 
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Status  of  This  Memo 

This  RFC  specifies  a  proposed  protocol  for  the  ARPA  Internet 
community,  and  requests  discussion  and  suggestions  for 
improvements.  Distribution  of  this  memo  is  unlimited. 
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CHAPTER  1 


Introduction 


The  Loader -O^ugger  Protocol  (LDP)  is  an  application  layer 
protocol  for  loading,  dunping  and  debugging  target  machines 
from  hosts  in  a  network  environment.  This  protocol  is  designed 
to  occonmodate  a  variety  of  target  cpu  types.  It  provides  a 
powerful  set  of  debugging  services.  At  the  same  time,  it  is 
structured  so  that  a  sinple  subset  may  be  iiiplemented  in 
Implications  like  boot  loading  where  efficiency  and  space  are 
at  a  premium. 


The  authors  would  like  to  thank  Dan  Franklin  and  Peter 
Cudhea  for  providing  many  of  the  ideas  on  which  this  protocol  is 
based. 


1.1  Purpose  of  This  Docuassit 

This  is  a  technical  specification  for  the  LDP  protocol.  It 
is  intended  to  be  coqprchensive  enough  to  be  used  by  Inpleoentors 
of  the  protocol.  It  contains  detailed  descriptions  of  the 
formats  and  usage  of  over  forty  coomands.  Readers  interested  in 
an  overviin/  of  LDP  should  read  the  Summary  of  Features,  below, 
and  skim  Sections  2  throu^  3.1.  Also  see  Appendix  B,  the 
Command  Suitsaary.  The  remainder  of  the  document  reads  best  when 
acconpanied  by  strong  coffee  or  tea. 
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1.2  Summary  of  Features 

IJDP  has  the  following  features: 

o  commands  to  perform  loading,  dumping  and  debugging 

o  support  for  multiple  connections  to  a  single  target 

o  reliable  performance  in  an  internet  environment 

o  a  small  protocol  subset  for  target  loaders 

o  addressing  modes  and  commands  to  support  multiple 
machine  types 


o  brealgpoints  and  watdpoints  \^ch  run  in  the  target 
machine . 
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CHAPTER  2 


General  Description 


2 . 1  Motivation 

LDP  is  an  application  protocol  that  provides  a  set  of 
commands  used  by  aj^lication  programs  for  loading,  dunping  and 
debugging  target  machines  across  a  network. 

The  goals  of  this  protocol  are  shown  in  the  following  list: 


o  The  protocol  should  sijpport  various  processor  types  and 
operating  systems.  Overhead  and  complexity  should  be 
niinlmlzed  for  siupler  cases. 


0  The  protocol  should  provide  support  for  applications  in 
which  more  than  one  use'"  can  d^ug  the  same  target 
machine.  This  Implies  an  underlying  transport  mechanism 
tliat  supports  multiple  connections  between  a  host-target 
pair. 


o  LDP  should  have  a  OLinimal  subset  of  commands  for  boot 
loading  and  dunping.  Target  machine  implementations  of 
these  a|p>lications  are  often  restricted  in  the  amount  of 
code -space  they  may  take.  The  services  needed  for 
loading  and  dunping  should  be  provided  in  a  small, 
easily  Implemented  set  of  commands. 


o  There  should  be  a  means  for  communicating  exception.^  and 
errors  from  the  target  LDP  process  to  the  host  process. 


o  LDP  should  allow  the  application  to  inplement  a  full  set 
of  debugging  functions  without  crippling  the  performance 
of  the  target’s  application  (i.e.,  PSN,  PAD,  gateway). 
For  example,  a  breakpoint  mechanism  that  halts  the 
target  machine  while  breakpoint  commands  are  sent  from 
the  host  to  the  target  is  of  limited  usefulness,  since 
the  target  will  be  unable  to  service  the  real-time 
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demands  of  its  application. 


2.2  Relation  to  Other  Protocols 

LDP  is  an  application  protocol  that  fits  into  the  layered 
internet  protocol  environment.  Figure  1  illustrates  the  place  of 
LDP  in  the  protocol  hierarchy. 


LDP 


+- 

I 

-»■- 


RDP 


or  1 


or 


TCP 


+ - + 

j  Internet  Protocol  | 


I 

-+ 


I  Network  Access  Protocol  | 


Application 

Layer 


Tr’ansport  Layer 


Internetwork 

Layer 


Network  Layer 


Relation  to  Other  Protocols 
Figure  1 
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2.2.1  Transport  Service  Requirements 

LDP  requires  that  the  underlying  transport  layer: 


o  allow  connections  to  be  opened  by  specifying  a  network 
(or  internet)  address.  Support  passive  and  active 
opens. 

o  for  each  connection,  specify  the  maximum  message  size. 

o  provide  a  mechanism  for  sending  and  receiving  messages 
over  an  op>en  connection. 

o  deliv^sr  messages  reli-ibly  and  in  sequence 

o  support  multiple  connections,  and  distinguish  messages 
associated  with  different  connections.  This  is  only  a 
requirement  where  LDP  is  expected  to  support  several 
users  at  the  same  time. 

o  explictly  return  the  outcome  (success/ failure)  of  each, 
request  (open,  send,  receive) ,  and  provide  a  means  of 
querying  the  status  of  a  connection  (unacknowledged 
message  count,  etc.) . 


Data  is  passed  from  the  application  program  to  the  LDP  user 
process  in  the  form  of  commands.  In  the  case  of  an  LDP  server 
process,  command  responses  originate  in  LDP  itself.  Below  LDP  is 
the  transport  protocol.  The  Reliable  Data  Protocol  (RDP  -- 
RFC  908)  is  the  recommended  transport  procotol .  Data  is  passed 
across  the  LDP,/RDP  interface  in  the  form  of  messages.  (TCP  may 
be  used  in  place  of  RDP,  but  it  will  be  less  efficient  and  it 
will  require  more  resources  to  implement.)  An  internet  layer 
(IP)  normally  comes  between  RDP  and  the  network  layer,  bv’.t  RDP 
may  exchange  data  packets  directly  with  the  network  layer. 

Figure  2  shows  the  flow  of  data  across  the  protocol 
inter  faces : 
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CHAPTER  3 


Protocol  Operation 


3 . 1  Overview 

An  LDP  session  consists  of  an  exchange  of  commands  and 
responses  between  an  LDP  user  process  and  an  LDP  server  process. 
Normally,  the  user  process  resides  on  a  host  machine  (a 
timesharing  computer  used  for  network  monitoring  and  control) , 
and  the  server  process  resides  on  a  target  machine  (PSN,  PAD, 
gateway,  etc.)  .  Througho’^^t  this  document,  host  and  target  are 
used  as  synonyms  for  user  process  and  server  process, 
respectively,  although  i,'i  some  inplementations  (the  Butterfly, 
for  example)  this  correspondence  may  be  reversed.  The  host 
controls  the  session  by  sending  commands  to  the  target.  Some 
commands  elicit  responses,  and  all  commands  may  elicit  an  error 
reply. 

The  protocol  contains  five  classes  of  commands:  protocol, 
data  transfer,  management,  control  and  breakpoint.  Protocol 
commands  are  used  to  verify  the  command  sequencing  mechanism  and 
to  handle  erroneous  commands.  Data  transfer  commands  Involve  the 
transfer  of  data  from  one  place  to  another,  such  as  for  memory 
examine/deposit,  or  loading.  Management  commands  are  used  for 
creating  and  deleting  objects  (processes,  breakpoints, 
watchpoints,  etc.)  in  the  target  machine.  Control  commands  are 
used  to  control  the  execution  of  target  code  and  brealq>oints . 
Breakpoint  commands  are  used  to  control  the  execution  of  commands 
inside  breakpoints  and  watc^oints. 


3.2  Session  Management 

An  LDP  session  consists  of  a  series  of  commands  sent  from  a 
host  LDP  to  a  target  LDP,  some  of  which  may  be  followed  by 
responses  from  the  target.  A  session  begins  when  a  host  opens  a 
transport  connection  to  a  target  listening  on  a  well  known  port. 
LDP  uses  RDP  port  number  zzz  or  TCP  port  number  yyy.  When  the 
connection  has  been  established,  the  host  sends  a  HELLO  command, 
and  the  target  replies  with  a  HELLO«REPLY.  The  HELLO«REPLY 
contains  parameters  that  describe  the  target's  implementation  of 
LDP,  including  protocol  version,  laplementation  level,  system 
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type,  and  address  format.  Ihe  session  terminates  when  the  host 
closes  the  underlying  transport  connection.  When  the  target 
detects  that  the  transport  connection  has  been  closed,  it  should 
deallocate  any  resources  dedicated  to  the  session. 

The  target  process  is  the  passive  partner  in  an  LDP  session, 
and  it  waits  for  the  host  process  to  terminate  the  session.  As 
an  iifflpiefflentation  consideration,  either  LDP  or  the  underlying 
transport  protocol  in  the  target  should  have  a  method  for 
detecting  if  the  host  process  has  died.  Otherwise,  an  LDP 
target  that  supported  only  one  connection  could  be  rendered 
useless  by  a  host  that  crashed  in  the  middle  of  a  session.  The 
problem  of  detecting  half-dead  connections  can  be  avoided  by 
taking  a  different  tack:  the  target  could  allow  new  connections 
to  usurp  inactive  connections.  A  connection  with  no  activity 
could  be  declared  'dead',  but  would  not  be  usm-ped  until  the 
connection  resource  was  needed.  However,  this  would  still 
require  the  transport  layer  to  support  two  connection  channels: 
one  to  receive  connection  requests,  and  another  to  use  for  an 
active  connection. 


3.3  Command  Sequencing 

Each  command  sent  from  the  host  to  the  target  has  a  sequence 
number.  The  sequence  number  is  used  by  the  target  to  refer  to 
the  command  in  normal  replies  and  error  replies.  To  save  space, 
these  numbers  are  not  actually  included  in  host  commands. 
Instead,  each  command  sent  from  the  host  is  assigned  an  implicit 
sequence  number.  The  sequence  number  starts  at  zero  at  the 
beginning  of  the  LDP  session  and  increases  by  one  for  each 
command  sent.  The  host  and  target  each  keep  track  of  the  current 
number.  The  SYNCH  <sequence  number>  command  may  be  used  by  the 
host  to  synchronize  the  sequence  number. 


3.4  Data  Packing  and  Transmission 

The  convention  for  the  order  of  data  packing  was  chosen  for 
its  slnpllclty :  data  are  packed  most  significant  bit  first,  in 
order  of  Increasing  target  address,  into  eight-bit  octets.  The 
octets  of  packed  data  are  transmitted  in  sequential  order. 
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Data  are  always  packed  according  to  the  address  format  of 
the  target  machine.  For  example,  in  an  LDP  session  between  a 
20 -bit  host  and  a  16 -bit  target,  16 -bit  words  (packed  into 
octets)  are  transmitted  in  both  directions.  For  ease  of 
discussion,  targets  are  treated  here  as  if  they  have  uniform 
address  spaces.  In  practice,  the  size  of  address  units  may  vary 
within  a  target  --  16 -bit  macromemory,  32 -bit  micromemory,  10 -bit 
dispatch  memory,  etc.  Data  packing  between  host  and  target  is 
tailored  to  the  units  of  the  current  target  address  space. 

Figures  showing  the  packing  of  data  for  targets  with  various 
address  unit  sizes  are  given  below.  The  order  of  transmission 
with  respect  to  th^  diagrams  is  top  to  bottom.  Bit  numbering  in 
the  following  diagrams  refers  to  significance  in  the  octet:  bit 
zero  is  the  least  significant  bit  in  an  octet.  For  an 
explanation  of  the  bit  numbering  convention  that  applies  in  the 
rest  of  this  document,  please  see  Afipendix  A. 

The  packing  of  data  for  targets  with  word  lengths  that  are 
multiples  of  8  is  straightforward.  The  following  diagram 
illustrates  16-bit  packing: 


Octet  0 


Octet  1 


Octet  2 


Octet  3 


Octet  2n-l 


1  WORD 

0 

bits 

15-08  1 

1  WORD 

0 

bits 

07-00  1 

1  WORD 

1 

bits 

15-08  1 

1  WORD 

1 

bits 

07-00  1 

* 

* 

* 

1  WORD 

n 

bits 

07-00  j 

Packing  of  16 -bit  Words 
Figure  3 
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Packing  for  targets  with  peculiar  word  lengths  is  more 
ccMSplicated.  For  20-bit  machines,  2  words  of  data  are  packed 
into  5  octets.  VIhen  an  odd  nuasber  of  20-bit  words  are 
transmitted,  the  partially  used  octet  is  included  in  the  length 
of  the  conmand,  and  the  octet  is  padded  to  the  right  with  zeroes. 


7  0 

Octet  0 
Octet  1 
Octet  2 
Octet  3 
Octet  4 


WORD  0  bits  19-12 
WORD  0  bits  11-04 
WORD  0  03-00  I  WORD  1  19-16 
WORD  1  bits  15-08 
WORD  1  bits  07-00 


Packing  of  20 -bit  Words 
Figure  4 


3.5  Is^^lementations 

A  subset  of  LDP  consnands  may  be  iieplemented  in  targets  where 
machine  resources  are  limited  and  the  full  capabilities  of  LDF 
are  not  needed.  There  are  three  basic  levels  of  target 
Implementations :  L0ADERJ3UMPER,  BASIC_J)EBUOGER  and 
FULL^PEBUOCER .  The  target  communicates  its  LDP  implementation 
level  to  tJie  host  during  session  Initiation.  The  implementation 
levels  are  described  below: 
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LOADEFU)UMPER 

Used  for  loadlng/dunplng  of  the  target  machine. 
Includes  all  protocol  class  connands  and  replies;  data 
transfer  commands  READ,  WRITE,  MOVE  and  their  responses; 
control  command  START  and  control  rqply  EXCEPTION. 
Understands  at  least  PHYS^MACRO  and  HOST  addressing  modes; 
others  if  desired. 

BASICJDEBUOCER 

Inplements  LQADE3LJXJMPER  commands,  all  control  commands, 
all  addressing  modes  appropriate  to  the  target  machine,  but 
does  not  have  finite  state  machine  (FSM)  breakpoints  or 
vatchpoints.  Default  brealqpoints  are  inplemented .  The 
target  understands  long  addressing  mode. 

FULLJ)E3U0GER 

Inpleokents  all  commands  and  addressing  modes  appropriate  to 
the  target  machine,  and  includes  brea]qx>int  connands, 
conditional  connands  and  BREAKPOINTJ>ATA.  Watchpoints  are 
optional . 


Page  13 


APPENDIX 


RFC  909 


LDP  Specification 


Commands  and  Formats 


CHAPTER  4 


Cosnnands  and  Formats 


4 . 1  Packet  Format 

LDP  commands  are  enclosed  in  RDP  transport  messages.  An  RDP 
message  may  contain  more  than  one  command,  but  each  command  must 
fit  entirely  within  a  single  message.  Network  packets  containing 
LDP  commands  have  the  format  shown  in  Figure  5. 
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Network  Packet  Format 
Figure  5 
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4.2  Command  Format 

LDP  commands  consist  of  a  standard  two -word  header  followed 
optionally  by  additional  data.  To  facilitate  parsing  of  multi¬ 
command  messages,  all  commands  contain  an  even  number  of  octets. 
Commands  that  contain  an  odd  number  of  data  octets  must  be  padded 
with  a  null  octet. 

The  commands  defined  by  the  LDP  specification  are  intended 
to  be  of  universal  application  to  provide  a  common  basis  for  all 
inplementations .  Command  class  and  type  codes  from  0  to  63.  are 
reserved  by  the  protocol.  Codes  above  63.  are  available  for  the 
implementation  of  target-specific  commands. 


4.2.1  Command  Header 

LDP  commands  begin  with  a  fixed  length  header.  The  header 
specifies  the  type  of  command  and  its  length  in  octets. 


0  0  0  1  1 
0123456789012  3  45 
+ - + - + 

0  I  Command  Length  (octets)  | 

+ - ^ - + 

1  I  Command  Class  |  Command  Type  | 
+ - - - + - + 


LDP  Command  Header  Format 
Figure  6 


HEADER  FIELDS; 

Command  Length 

The  command  length  gives  the  total  number  of  octets  in  the 
command,  including  the  length  field  and  data,  and  excluding 
podding. 

Command  Class 
Command  Type 
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The  command  class  and  type  together  specify  a  particular 
command.  Ilie  class  selects  one  of  six  command  categories, 
and  the  type  gives  the  command  within  that  category.  All 
codes  are  decimal.  The  symbols  given  in  Figures  7  and  S  for 
command  classes  and  types  are  used  in  the  remainder  of  this 
document  for  reference. 

The  command  classes  that  have  been  defined  are; 


Command  Class 


1 

2 

3 

4 

5 

6 

7-63 


j  Symbol 


I  P?v0T0C0L 
I  DATA..TRANSFER 
j  CONTROL 
I  MANAGEMENT 
I  BREAKPOINT 
I  CONDITION 
1  <reserved> 


Command  Classes 
Figure  7 


Command  type  codes  are  assigned  in  order  of  expected 
frequency  of  use.  Commands  and  their  responses/replies  are 
numbered  sequentially.  The  command  ty^s,  ordered  by 
command  class,  are: 
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Command  Class  {  Command  Type 

1 

Symbol 

“T* 

PROTOCOL  1 
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HELLO 
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HELLO_REPLY 
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3 
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SYNCH 
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4 
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ERROR 
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ERRACK 

1 

7 
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ABORT 

1 

8 

i 

ABORT_PONE 
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1 

9  - 
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1 

<reserved> 

DATA^TRANSFER  | 

1 
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1 

WRITE 
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1 

READ 

1 
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1 

READ_DONE 

1 

4 

1 

READJDATA 

1 
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MOVE 
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MOVE_DONE 
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7 

1 

MOVEJDATA 
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8 
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REPEATJDATA 

1 

9 

1 

BREAKPOINTJDATA 

1 

10 

1 

WRITE_MASK 

! 

1 

11 

-  63 

1 

1 

<reserved> 

COiriBOL  i 

1 

1 

1 

START 

I 

2 

1 

STOP 

1 

3 

1 

CONTINUE 

1 

4 

1 

STEP 

1 

5 

1 

REPORT 

1 

6 

1 

STATUS 

1 

7 

1 

EXCEPTION 
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j 

8  - 

63 

j 

i 

<reserved> 

MANAGEMENT  | 

1 

1 

1 

CREATE 

1 
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1 

CREATE  JDONE 

1 

3 

1 

DELETE 

1 

4 

1 

DELETE  JDONE 

j 

5 

1 

LIST_ADDRESSES 

! 

6 

1 

1 

ADDPvESS^IST 

1 
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! 

GET^HYSJ^DRESS 

1 

8 

1 

COTJWS_ADDRESS 

1 

9 

1 

GEr.OBJECT 
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10 
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COT.OBJECT 

i 

11 
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LIST_SR£AKPOINTS 

1 

1 

12 

1 

BREAKPOINT.LIST 
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CONDITION 
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13 
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14 
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15 
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16 
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PROCESSJLIST 

17  -  63 
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<reserved> 
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1 

INCREMENT 
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1 

INC_C0UNT 

3 

1 

OR 

4 

1 

SLT^PTR 
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1 

SET.STATE 

6-63 
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<reserved> 
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1 

CHANGED 

2 

1 

COMPARE 

3 

1 

COUNT.EQ 

4 

1 

coi»n-_aT 

5 

1 

COUNTJLT 

6 

1 

TEST 

7-63 

i 

<reserved> 

Command  Types 
Figure  3 


4 . 3  Addressing 

/ddr esses  are  used  in  LDP  commands  to  refer  to  memory 
locations,  processes,  buffers,  breakpoints  and  other  entities. 
Many  of  these  entitles  are  machine -dependent;  some  machines  have 
named  objects,  some  machines  have  multiple  address  spaces,  the 
size  of  address  spaces  varies,  etc.  The  format  for  specifying 
addresses  needs  to  be  general  enough  to  handle  all  of  these 
cases.  This  speaks  for  a  large,  hierarchically  structured 
address  format.  Howcr/er,  the  disadvantage  of  a  large  format  is 
that  it  laposes  extra  overhead  on  communication  with  targets  that 
have  slnpler  address  schemes. 

LDP  resolves  this  conflict  by  enploylng  two  address  formats: 
a  short  three- word  format  for  addressing  sinpler  targets,  and  a 
long  five-word  format  for  others.  Each  target  LDP  is  rcgu^rec  to 
iBplement  at  least  one  of  these  formats.  At  the  start  of  an  LDP 
session,  the  target  specifies  the  address  format (s)  it  uses  in 
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the  Elag  field  of  the  HELLO JREPLY  message.  In  each  address,  the 
first  bit  of  the  mode  octet  is  a  format  flag:  0  indicates  LONG 
address  format,  and  l^indj. cates  SHORT  format. 


4.3.1  Long  Address  Format 

The  long  address  format  is  five  words  long  and  consists  of  a 
three-word  address  descriptor  and  a  two- word  offset  (see  Figure 
9)  .  The  descriptor  spjecifies  an  address  space  to  which  the  offset 
is  applied.  The  descriptor  is  subdivided  into  several  fields,  as 
described  below.  The  structuring  of  the  descriptor  is  designed 
to  support  complex  addressing  modes.  For  example,  on  targets 
with  multiple  processes,  descriptors  may  reference  virtual 
addresses,  registers,  and  other  entities  within  a  particular 
process . 

The  addressing  modes  defined  below  are  intended  as  a  base  to 
which  target -specific  modes  may  be  added.  Modes  up  to  63.  are 
reserved  by  the  protocol.  The  range  64.  to  127.  may  be  used  for 
target -specific  address  modes. 


Long  Format  •*  Format  bit  is  L0NG=0 

0  0  0  1  1 
0123456789012345 


|0| 

Mode  1  Mode  Arg 

1 

1 

1 

(31-16) 

ID 

(15-0) 

1 

- -f 

1 

1 

1 

+ - 

(31-16) 

Offset 

(15-0) 

•  W  W  W  ^ 

1 

- -f 

1 

Descriptor 


Offset 


Long  Address  Format 
Figure  9 


LONG  ADDRESS  FIELDS: 
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Mode 

The  address  mode  identifies  the  type  of  address  space  being 
referenced.  The  mode  is  qualified  by  the  mode  argument  and 
the  ID  field.  Implementation  of  modes  other  than  physical 
and  host  is  machine -dependent.  Currently  defined  modes  and 
the  address  space  they  reference  are  shown  in  Figure  10. 


Mode  I  Symbol 
- + - 


]  Address  ^ace 
+ - 


0 

HOST 

1 

PHyS_MACRO 

2 

PHYS_MICRO 

3 

PHTS^I/O 

4 

PHYS_MACRO_PTR 

5 

PffifSJlEG 

6 

PHYSJlEG_OFFSET 

7 

PHYSJlEG.INDIRECr 

8 

PROCESS.CODE 

9 

PROCESS JDATA 

10 

PROCESS JDATA.J>TR 

11 

PROCESSJIEG 

12 

PROCESSJREG.OFFSET 

13 

PROCESSJIEG.INDIRECT 

14 

OBJECT.OFFSET 

15 

0BJECT,J1EADER 

16 

BREAKPOINT 

17 

WATCHPOINT 

18 

BPTJPTO^OFFSET 

19 

HPT,J>TR^INDIRECT 

20  - 
63 

<rcserved> 

Host 

Macromemory 
Micromemory 
I/O  qpace 

Macro  contains  a  pointer 
Register 

Register  plus  offset 
Register  contains  address 
of  a  pointer 

Process  code  qpace 
Process  data  space 
Process  data  contains  a  ptr 
Process  virtual  register 
Process  register  plus  offset 
Process  register  contains 
address  of  a  pointer 

Memory  object  (queue,  pool) 
System  header  for  an  object 
Brealq>oint 
Watchpoint 

Brealq>olnt  ptr  plus  offset 
Breakpoint  ptr  plus  offset 
gives  address  of  a  pointer 


Long  Address  Modes 
Figure  10 


Mode  Argument 
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Provides  a  numeric  argument  to  the  mode  field.  Specifies 
the  register  in  physical  and  process  REG  and  REG_OFFSET 
modes. 


ID  Field 


Identifies  a  particular  process,  buffer  or  object. 

Offset 

The  offset  into  the  linear  address  space  defined  by  the 
mode.  The  size  of  the  machine  word  determines  the  number  of 
significant  bits  in  the  offset.  Likewise,  the  addressing 
units  of  the  target  are  the  units  of  the  offset. 

The  interpretation  of  the  mode  argument,  ID  field  and  offset  for 
each  address  mode  is  given  below: 


HOST 


The  ID  and  offset  fields  are  numbers  assigned  arbitrarily  by 
the  host  side  of  the  d^ugger.  These  nuiabers  are  used  in 
MOVE  and  MOVEJIATA  messages.  MOVE_PATA  responses  containing 
this  mode  as  the  destination  are  sent  by  the  target  to  the 
host.  This  may  occur  in  debugging  when  data  is  sent  to  the 
host  from  the  target  breakpoint. 


PHYS^CRO 


The  offset  contains  the  32 -bit  physical  address  of  a 
location  in  macromemory.  The  mode  argument  and  ID  field  are 
not  used.  For  example,  mode=PHYS_MACRO  and  offset=1000 
specifies  location  1000  in  physical  memory. 


PHYS.  MICRO 


Like  PHYS_MACRO,  but  the  location  is  in  micromemory. 

PHYS_I/0 

Like  PHYS_MACRO,  but  the  location  is  in  I/O  space. 
PHYS_MACROJ>TR 

The  offset  contains  the  address  of  a  pointer  in  macromemory. 
The  location  pointed  to  (the  effective  address)  is  also  in 
macromemory.  The  mode  argument  and  ID  field  are  unused. 
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PHfSJlEG 

The  mode  argument  gives  the  physical  register.  If  the 
register  is  used  by  the  LDP  target  process,  then  the  saved 
copy  from  the  previous  context  is  used.  This  comment 
applies  to  PHYS^G_OFFSET  mode  as  well.  The  ID  field  is 
not  used. 

PHfS^G^OFFSET 

The  offset  is  added  to  the  contents  of  a  register  given  as 
the  mode  argument.  The  result  is  used  as  a  physical  address 
in  macromemory.  ID  is  unused. 

PHYS^G.INDIRECT 

The  register  specified  in  the  mode  arg  contains  the  address 
of  a  pointer  in  macromemory.  The  effective  address  is  the 
macromemory  location  specified  in  the  pointer,  plus  the 
offset.  The  ID  field  is  unused. 

PROCESS^CODE 

The  ID  is  a  process  ID,  the  offset  is  into  the  code  space 
for  this  process.  Mode  argument  is  not  used. 

PROCESSJDATA 

The  ID  is  a  process  ID,  the  offset  is  into  the  data  space 
for  this  process.  Mode  argument  is  not  used.  On  systems 
that  do  not  distinguish  between  code  and  data  space,  these 
two  modes  are  equivalent,  and  reference  the  virtual  address 
space  of  the  process. 

processjdat;»l-Ptr 

The  offset  contains  the  address  of  a  pointer  in  the  data 
space  of  the  process  specified  by  the  ID.  The  location 
pointed  to  (the  effective  address)  is  also  in  the  data 
space.  The  mode  argument  is  not  used. 

PROCESSJIEG 

Accesses  the  registers  (and  other  system  data)  of  the 
process  givcjn  by  the  ID  field.  Mode  argument  0  starts  tiie 
registers.  After  the  registers,  the  mode  argument  is  an 
offset  into  the  system  area  for  the  process. 
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PROCESSJIEG.OFFSET 

■nie  offset  plus  the  contents  of  the  register  given  in  the 
mode  argument  specifies  a  location  in  the  data  ^ace  of  the 
process  specified  by  the  ID. 

PROCESS JIEG^INDIRECT 

Ihe  register  specified  in  the  mode  arg  contains  the  address 
of  a  pointer  in  the  data  space  of  the  process  given  by  the 
ID.  The  effective  address  is  the  location  in  process  data 
space  specified  in  the  pointer,  plus  the  offset. 

OBJECT^OFFSET  (optional) 

The  offset  is  into  the  memory  space  defined  by  the  object  ID 
in  ID.  Recommended  for  remote  control  of  parameter 
segments . 

OBJECT.JJEADER  (optional) 

The  offset  is  into  the  system  header  for  the  object 

specified  by  the  ID.  Intended  for  use  with  the  Butterfly  . 

BREAKPOINT 

The  descriptor  specifies  a  brealqpoint.  The  offset  is  never 
used,  this  type  is  only  used  in  descriptors  referring  to 

brealq>Dints .  (See  Brealqpoints  and  Watc^points,  below,  for 
an  explanation  of  breakpoint  descriptors.) 

WATCHPOINT 

The  descriptor  specifies  a  watchpolnt.  The  offset  is  never 
used,  this  type  is  only  used  in  descriptors  referring  to 

watdfpolnts.  (See  Breakpoints  and  Watchpoints,  below,  for 
an  e3g>lanatlon  of  watclqpoint  descriptors)  . 

BPTJPTK.OFFSET 

For  this  mode  and  BPTJPTR_INDIRECT,  the  mode  argument 
specifies  one  of  two  breaJg>olnt  pointer  variables  local  to 
the  breakpoint  in  which  this  address  occurs.  These  pointers 
and  the  SETJPTR  command  which  manipulates  them  provide  for 
an  arbitrary  amount  of  address  indirection.  They  are 
intended  for  use  in  traversing  data  structures:  for  example, 
chasing  queues.  In  BPT_PTRs_OFFSET,  the  offset  is  added  to 
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the  pointer  variable  to  give  the  effective  address.  In 
targets  which  sugfport  multiple  processes,  the  location  is  in 
the  data  i^ace  of  the  process  given  by  the  ID.  Otherwise, 
the  location  is  a  physical  address  in  macro-memory. 
BPT^PIR.*  modes  are  valid  only  in  breakpoints  and 
watcl^oints . 

BPTJPTR^INDIRECT 

Like  BPTJP1K_0FFSET,  except  that  it  uses  one  more  level  of 
indirection.  The  pointer  variable  given  by  the  mode 
argurnent  plus  the  offset  specify  an  address  which  points  to 
the  effective  address.  See  the  description  of 
HPTJPTR_OFFSET  for  a  discussion  of  usage,  limitations  and 
address  space. 


4.3.2  Short  Address  Format 


The  short  address  format  is  intended  for  use  in 
in^^lementations  where  protocol  overhead  must  be  minimized.  This 
format  is  a  subset  of  the  long  address  format:  it  contains  the 
same  fields  except  for  the  ID  field.  Therefore,  the  short 
addressing  format  supports  only  HOST  and  PHYS_*  address  modes. 
Only  the  L0ADEKJ5UMPER  in^jlementation  level  commands  may  be  used 
with  the  short  addressing  format.  The  short  address  format  is 


three  words  long,  consistiriy  o£  a  io-bit  word  describing  the 
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Short  Format  -  Format  bit  is  SH0RT=1 
< 


0  0  0  1  1 
0123456789012345 

+ - - - + 

11 1  Mode  I  Mode  Argument  | 

^ - + 

I  (31-16)  I  I 

+ -  Offset  — +  I  Offset 

I  (15-0)  I  I 

^ - ^  +-4. 


Short  Address  Format 
Figure  11 


SHORT  ADDRESS  FIELDS: 
Mode 


The  high- order  bit  is  1,  indicating  the  short  address 
format.  A  list  of  the  address  modes  supported  is  given 
below.  The  interpretation  of  the  remaining  fields  is  as 
described  above  for  the  long  addressing  format. 
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Mode  I  Symbol 
- + - 

0  HOST 

1  PffifSJIACRO 

2  PHYS_MICRO 

3  PHYS_I/0 

4  PHySJ^ACRO.J>TO 

5  PffifSJtEG 

6  PHYSJIEG.OFFSET 

7  PHYSJtEG.INDIRECr 

8  - 

32  <reserved> 


i  Address  space 


Host 

Macro -memory 
Micro -memory 
I/O  space 

Macro  contains  a  pointer 
Register 

Register  plus  offset 
Register  contains  address 
of  a  pointer 


Short  Address  Modes 
Figure  12 
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CHAPTER  5 

Protocol  Commands 


Protocol  commands  are  used  for  error  handling,  for 
synchronizing  the  command  sequence  number  ,  and  for  communicating 
protocol  inplementatlon  parameters.  Every  protocol  command  has  a 
corresponding  reply.  All  protocol  commands  are  sent  from  the 
host  to  the  target,  with  replies  flowing  in  the  opposite 
direction. 


5 . 1  HELLO  Comnand 

Ihe  HELLO  comnand  is  sent  by  the  host  to  signal  the  start  of 
an  LDP  session.  The  target  responds  with  HELLO JIEPLY. 


0  0  0  1  1 
0123456789012345 


^ - 

0  1 

4 

- ^ 

1 

•  •  • 

1  1  PROTOCOL 
- - - 

1 

HELLO 

1 

- 4 

HELLO  Comnand  Format 
Figure  13 


5.2  HELLO JIEPLY 

A  HELLOJREPLY  is  sent  by  the  target  in  response  to  the  HELLO 
comnand  at  the  start  of  an  LDP  session.  This  reply  is  used  to 
inform  the  host  about  the  target *s  implementation  of  LDP. 


I*,  / 


ii- 


V*j 


m 
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0  0  0  1  1 
0123456789012345 
+ - - + 

0  I  10  I 

1  I  PROTOCOL  I  HELLOJ^LY  \ 

+ - + - + 

2  I  LDP  Version  |  System  Type  j 

+ - —  -  - - 

3  I  Options  |W|Sj  Inplementation  I 

+ - + - + 

4  I  Address  Code  |  Reserved  | 

+ - + - + 


HELLO_REPLY  Format 
Figure  14 


HELLO_REPLY  FIELDS; 

LDP  Version 

The  target’s  LDP  protocol  version.  If  the  current 
host  protocol  version  does  not  agree  with  the  target's 
protocol  version,  the  host  may  terminate  the  session,  or 
may  continue  it,  at  the  discretion  of  the  inplementor .  The 
currant  version  number  is  2. 

System  Type 


The  type  of  systisi  runriiag  on  tiis  targv^t.  This  is  used  as  a 
check  against  what  the  host  thinks  the  target  is.  The  host 
is  expected  to  have  a  table  of  target  system  types  with 
information  about  target  address  spaces,  target-specific 
commands  and  addressing  modes,  and  so  forth. 

Currently  defined  system  types  are  shown  in  Figure  15.  This 
list  Includes  some  systems  normally  thou-^t  of  ar  'hosts’ 
(e.g.  C70,  VAX),  for  Inplementations  where  targets  actively 
initiate  and  direct  a  load  of  themselves. 
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C30_16_BIT 

C30_20_BIT 

H316 

BUTTERFLY 

PDP-11 

CIO 

C50 

PLURIBUS 

C70 

VAX 

MACINTOSH 


I  Description 

-+ - 

BBN  16-bit  C30 
BBN  20 -bit  C30 
Honeywel 1 - 316 
BBN  Butterfly 
DEC  PDP-11 
BBN  CIO 
BBN  C50 
BBN  Pluribus 
BBN  C70 
DEC  VAX 

Apple  Macintosh 


Address  Code 


System  Types 
Figure  15 


The  address  code  indicates  vfhich  LDP  address  format  (s)  the 
target  is  prepared  to  use.  Address  codes  are  show  in  Figure 
16. 


Address  Code  I  Symbol 


Description 


1 

LONG,J>aDDRESS 

Five  word  address  format. 
Supports  all  address  modes 
and  commands. 

SHORT^DRESS 

Three  word  address  format. 
Supports  only  physical  and 
host  address  modes.  Only 
the  LOADERJDUMPER  set  of 
commands  are  sipported. 

Target  Address  Codes 

Figure  1€ 

Inplementation 
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The  inplementation  level  specifies  v»hich  features  of 
the  protocol  are  inplemented  in  the  target.  There  are 
three  levels  of< protocol  inplementation.  These  levels  are 
intended  to  correspond  to  the  three  most  likely  applications 
of  LDP:  sinple  loading  and  dumping,  basic  debugging,  and 
full  debugging.  (Please  see  Implementations,  above,  for  a 
detailed  description  of  implementation  levels.)  There  are 
are  also  several  optional  features  that  are  not  included  in 
any  particular  level . 

Implementation  levels  are  cumulative,  that  is,  each  hi^er 
level  Includes  the  features  of  all  previous  levels.  The 
levels  are  shown  in  Figure  17. 


Feature  Level  |  Symbol  j  Description 

- + - + - 

1  LOADERJDUMPER  Loader /dunper  subset  of  LDP 

2  BASICJDEBUGGER  Control  commands,  CREATE 

3  FULLJDEBUOGER  FSM  breakpoints 


Feature  Levels 
Figure  17 


Cations 

The  options  field  (see  Figure  18)  is  an  eight -bit  flag 
field.  Bit  flags  are  used  to  indicate  if  the  target  has 
implemented  particular  optional  commands.  Not  all  optional 
commands  are  referenced  in  this  field.  Commands  whose 
Inplementation  depends  on  target  machine  features  are 
omitted.  The  LDP  application  is  expected  to  'know'  about 
target  features  that  are  not  intrinsic  to  the  protocol . 
Examples  of  target -dependent  commands  are  commands  that 
refer  to  named  objects  (CREATE,  LIST_NA.MES)  . 
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Mask  j  Symbol  |  Description 
- + - + - + - 

1  STEP  Ihe  STEP  command  is  inplemented 

2  WATCHPOINTS  Watcbpoints  are  iisplemented 


Options 
Figure  18 


5.3  SYNCH  Command 

The  SYNCH  command  is  sent  by  the  host  to  the  target.  The 
target  responds  with  a  SYNCHJIEPLY.  The  SYNCH  -  SYNCHJIEPLY 
exchange  serves  two  functions:  it  synchronizes  the  host -to -target 
implicit  sequence  number  and  acts  as  a  cumulative  acknowledgement 
of  the  receipt  and  execution  of  all  host  commands  \jp  to  the 
SYNCH. 


0  0  0  1  1 
0123456789012345 

4 - ^ - 4 

0  I  6  I 

^ - ^ - ^ 

1  I  PROTOCOL  I  SYNCH  | 

+ - ^ - ^ 

2  I  Sequence  Number  | 

^ - + - 


SYNCH  Command  Format 
Figure  19 


SYNCH  FIELDS: 
Sequence  Number 
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The  sequence  number  of  this  command.  If  this  is  not  what 
the  target  is  expecting,  the  target  will  reset  to  it  and 
respond  with  an  £RROR  reply. 


5.4  SYNOUtEPLY 

A  SYNCH_REPLY  is  sent  by  the  target  in  reponse  to  a  valid 
SYNCH  command.  A  SYNCH  command  is  valid  if  its  se'quence  number 
agrees  with  the  sequence  nmnber  the  target  is  expecting. 
Otherwise,  the  target  will  reset  its  sequence  number  to  the  SYNCH 
command  and  send  an  ERROR  reply. 


0  0  0  1  1 
0123456789012345 


PROTXXOL 


SYNCH-REPLY  | 


Sequence  Number 


SYNOLREPLY  Format 
Figure  20 


SYNCH-REPLY  FIELDS: 

Sequence  Number 

The  sequence  number  of  the  SYNCH  command  to  which  this 
SYNCH-REPLY  is  the  response. 
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5 . 5  ABORT  Command 

Ihe  ABORT  command  is  sent  from  the  host  to  abort  all  pending 
operations  at  the  t;arget.  The  target  responds  with  AB0RT_D0NE. 
This  is  primarily  intended  to  stop  large  data  transfers  from  the 
target.  A  likely  application  would  be  during  a  debugging  session 
when  the  user  types  an  interrupt  to  abort  a  large  printout  of 
data  from  the  target.  The  ABORT  command  has  no  effect  on  any 
breakpoints  or  watclpoints  that  may  be  enabled  in  the  target. 

As  a  practical  matter,  the  ABORT  command  may  be  difficult  to 
inplement  on  some  targets.  Its  ability  to  Interrupt  command 
processing  on  the  target  dep>ends  on  the  target  being  able  to  look 
ahead  at  incoming  commands  and  receive  an  out-of-band  signal  from 
the  host.  However,  the  effect  of  an  ABORT  may  be  achieved  by 
slnply  closing  and  reopening  the  transport  connection. 


0 

0 

0  0 

12345678 

1 

9  0  12 

1 

3  4  5 

0  i 

^  ^  m 

4 

1  1 

PAOTXXOL  i 

ABORT 

ABORT  Command  Format 
Figure  21 


5.6  ABORT^NE  Reply 

The  AB0RTJX>r4E  reply  is  sent  from  the  target  to  the  host  in 
response  to  an  AIKDRT  command.  This  indicates  that  the  target  has 
terminated  all  operations  that  were  pending  when  the  ABORT 
command  was  received.  The  sequence  number  of  the  ABORT  command 
is  included  in  the  reply. 
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0  .  0  0  1  1 
0123456789012345 
+ - + - + 

0  I  4  I 

+ - + - + 

1  I  PROTOCOL  I  ABORTJDONE  | 

+ - + — - ^ 

2  I  Sequence  Number  { 

^ - + - ^ 


ABORT_JX)NE  Reply  Format 
Figure  22 


ABORTJX)NE  FIELDS: 

Sequence  Number 

The  sequence  number  of  the  ABORT  command  that  elicited  this 
reply.  This  enables  the  host  to  distinguish  between 
replies  to  multiple  aborts. 


5 , 7  ERROR  Reply 

The  ERROR  reply  is  sent  by  the  target  in  response  to  a  bad 
command.  The  ERROR  reply  gives  the  .seqp-ience  number  of  the 
offending  command  and  a  reason  code.  The  target  ignores  further 
commands  until  an  ERRACK  command  is  received.  The  reason  for 
Ignoring  commands  is  that  the  proper  operation  of  outstanding 
commands  may  be  predicated  on  the  execution  of  the  erroneous 
command . 
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0  0  0  1  1 
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+ - ^ - ^ 
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+ - + - ^ 

I  PROTOCOL  I  ERROR  | 

+ - - ^ 

I  Command  Sequence  Number  { 

^ - + - ^ 

I  Error  code  j 

+ - + - ^ 

I  Optional  Data  | 

+ - ^ - ^ 

* 
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* 

+ - -->f 

I  Optional  Data  | 

+ - ^ - ^ 


OIRC^  Reply  Format 
Figure  23 


ERROR  Reply  FIELDS: 

Command  Sequence  Number 

ihc  Implicit  sequence  number  of  the  erroneous  command. 

Error  Code 

A  code  specifying  what  error  has  taken  place.  The  currently 
defined  codes  are  shown  in  Figure  24. 
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Error^Code  1  Symbol 


1  BAD^COMMAND 

2  BAD^DR£SS_MODE 

3  BAD^DR£SS_ID 

4  BAD_;^DDR£SS.OFESET 

5  BAD_CREATE_TYPE 

6  N0_RES0URCES 

7  NO.OBJECT 

8  0UT_0F_SYNCH 

9  IN_BREAKPOINT 


ERROR  Codes 
Figure  24 


An  ejgjlanatlon  of  each  of  these  error  codes  follows: 
BAD_C(>MAND 

The  command  was  not  meaningful  to  the  target  machine. 
This  includes  commands  that  are  valid  but  uninplemented 
in  this  target.  Also,  the  command  was  not  valid  in 
this  context.  For  exaaple,  a  command  given  by  the  host 
that  is  only'  legal  in  a  breakpoint  (e.g.  IF, 
SET^STATE) . 

BAD_ADDRESS.J10DE  <o f f ending-address> 

The  mode  of  an  address  given  in  the  command  is  not 
meaningful  to  this  target  system.  For  exanple.  a 
PROCESS  address  mode  on  a  target  that  does  not  support 
multi -processing . 

BAD_,ADDRESS_ID  <of fending -address > 

The  ID  field  of  an  address  didn’t  correspond  to  an 
appropriate  thing.  For  example,  for  a  PROCESS  address 
mode,  the  ID  of  a  non-existent  process. 

RAD_>DDRESS_OFFSET  <of fending -address > 

The  offset  field  of  the  address  was  outside  the  legal 
range  for  the  thing  addre:  sed.  For  exanple,  an  offset 
of  200,000  in  PHYSJIACRC  mode  on  a  target  witl;  64K  of 
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macro -memory . 

BAD^CREATELTYPE 

< 

The  object  type  In  a  CREATE  command  was  unknown. 
NOJIESOURCES 

A  CREATE  command  failed  due  to  lack  of  necessary 
resources . 

NO.OBJECT 

A  GET^OBJECT  connand  failed  to  find  the  named  object, 
OUT_OF_SYNCH 

The  sequence  number  of  the  SYNCH  command  was  not 
esqpected  by  the  target.  The  target  has  resynchronized 
to  It. 

INJBREAKPOINT  <brealqpolnt-descrlptor>  <brea}q>olnt- sequence# > 
<reason-code>  [<qptlonal-info>] 

An  error  occurred  within  a  breakpoint  command  list. 
Ihe  given  16 -bit  sequence -number  riifers  to  the  sequence 
number  of  the  CREATE  command  that  created  the 
brea}qx>lnt,  wlii'.e  breakpoint-sequence#  refers  to  the 
sfKjuonce  number  of  the  command  within  the  breakroint 
given  by  <breakpolnt-descrlptor> . 


5 . 8  ERRACK  Acknowledgement 

An  ERRACK  Is  sent  by  the  host  In  response  to  an  ERROR 
reply  from  the  target.  The  ERRACK  Is  used  to  acknowledge  that 
the  host  has  received  the  ERROR  reply. 
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0  ,  0  0  1  1 
0123456789012345 

+ - -f - -f 

0  .  4  I 

+ - + - + 

1  I  PROTOCOL  I  ERRAOC  | 

•f - + - + 

ERRACK  Command  Format 
Figure  25 
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CHAPTER  6 


€ 

Data  Transfer  Commands 


Data  transfer  commands  transfer  data  between  the  host  and 
the  target.  These  commands  are  used  for  loading  and  dumping  the 
target,  and  examining  and  depositing  locations  on  the  target. 
The  READ  command  reads  data  from  the  target,  the  MOVE  command 
moves  data  within  the  target  or  from  the  target  to  another 
entity,  and  the  WRITE  command  writes  data  to  the  target. 
REPEAT_J)ATA  makes  copies  of  a  pattern  to  the  target  --  it  is 
useful  for  zeroing  memory.  WRITE_MASK  writes  data  with  a  mask, 
and  is  intended  for  modifying  target  parameter  tables. 

Data  transmitted  to  and  from  the  target  always  contains  a 
target  address.  In  writes  to  the  target,  this  is  used  as  the 
destination  of  the  data.  In  reads  from  the  target,  the  target 
address  is  used  by  the  host  to  idwitify  where  in  the  target  the 
data  came  from.  In  addition,  the  MOVE  command  may  contain  a 
'host'  address  as  its  destination;  this  permits  the  host  to 
further  discriminate  between  possible  sources  of  data  from  the 
target  --  from  different  breakpoints,  debugging  windows,  etc. 

A  read  request  to  the  target  may  generate  one  or  more 
response  messages.  In  particular,  responses  to  requests  for 
large  amounts  of  data  --  core  dumps,  for  example  --  must  be 
broken  up  into  multiple  messages,  if  the  block  of  data  requested 
plus  the  LDP  header  exceeds  the  transport  layer  message  size. 

In  commands  which  contain  data  (WRITE,  READJ3ATA,  MOVEJDATA 
and  REPEATJDATA)  ,  if  there  are  an  odd  number  of  data  octets,  then 
a  null  octet  is  appended.  This  is  so  that  the  next  conanand  in 
the  message,  if  any,  will  begin  on  an  even  octet.  The  command 
l«ngth  is  the  sum  of  the  number  of  octets  in  the  command  header 
and  the  number  of  octets  of  data,  excluding  the  null  octet,  if 
any. 

The  addressing  formats  which  may  be  used  with  data  transfer 
commands  are  spjecified  for  each  LDP  session  at  the  start  of  the 
session  by  the  target  in  the  HELLO JIEPLY  response.  See  the 
section  entitled  'Addressing',  above,  for  a  description  of  LDP 
addressing  formats  and  modes.  In  the  command  diagrams  given 
below,  the  short  addressing  format  is  illustrated.  For  LDP 
sessions  using  long  addressing,  addresses  are  five  words  long. 
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instead  of  three  words,  as  shown  here.  In  both  addresring  modes, 
descriptors  are  three  words  and  offsets  are  two  words. 


6 . 1  WRITE  Command 

Ihe  WRITE  command  is  used  to  send  octets  of  data  from  the 
host  to  the  target.  This  command  specifies  the  address  in  the 
target  where  the  data  is  to  be  stored,  followed  by  a  stream  of 
data  octets.  If  the  data  stream  contains  an  odd  number  of 
octets,  then  a  null  octet  is  appended  so  that  the  next  command, 
if  any,  will  begin  on  an  even  octet.  Since  LDP  must  observe 
message  size  limitations  lopossxl  by  the  underlying  transp>ort 
layer,  a  single  logical  write  may  need  to  be  broken  up  int- 
multiple  WRITES  in  separate  transport  messages. 


0  0  0  1  1 
0123456789012345 


Command  Length 


1  I  DAT\_1RANSFER  |  WRITE 


Target 

Start 

Address 


5  I  Data  Octet  |  D.-ita  Octet 


n  j  Data  Octet  |  Data  or  Null  | 


WRITE  Command  Format 
Figure  26 
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WRITE  FIELDS: 

Coiomand  Length 

The  command  length  gives  the  number  of  octets  in  the 
command,  including  data  octets,  but  excluding  the  padding 
octet,  if  any. 

Target  Start  Address 

This  is  tlie  address  to  begin  storing  data  in  the  target. 
The  lergth  of  the  data  to  be  stored  may  be  inferred  by  the 
target  from  the  command  length.  An  illegal  address  or  range 
will  generate  an  reply. 

Data  Octets 

Octets  of  data  to  be  stored  in  the  target.  Data  are  packed 
according  to  the  packing  convention  described  above.  Ends 
with  a  null  octet  if  there  are  an  odd  number  of  data  octets. 


6 . 2  READ  Command 

The  host  uses  the  READ  concAand  to  ask  the  target  to 
send  back  a  contiguous  block  of  data.  The  data  is  specified  by 
a  target  starting  address  and  a  count.  The  target  returns  the 
data  in  one  or  more  READJDiATA  consnands,  which  give  the  starting 
address  (in  the  target)  of  each  segment  of  returned  data.  When 
the  transfer  is  completed,  the  target  sends  a  READJXH^  command 
to  the  host . 
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0  0  0  1  1 
0123456789012345 


- 

0  1 

- + - 

14 

1 

1  i  DATA^TRANSFER  |  READ  | 

2  i 

3  1 

4  1 

Target 

Start 

Address 

1 

--+ 

1 

1 

5  1 

6  1 

- 

Address 

Unit 

Count 

1 

1 

READ  Command  Format 
Figure  27 


READ  FIELDS: 

Target  Start  Address 

Ihe  starting  address  of  the  requested  block  of  target  data. 
Ihe  target  sends  an  ERROR  reply  if  the  starting  address  Is 
Illegal,  If  the  ending  address  confuted  from  the  sum  of  the 
start  and  the  count  is  illegal,  or  If  holes  are  encountered 
in  the  middle  of  tiie  range. 

Address  Unit  Count 

The  count  of  the  number  of  target  Indlvlslbly-addressable 
units  to  be  transferred.  For  exajqple.  If  the  address  space 
Is  PHTS.WACRO.  a  count  of  two  and  a  start  address  of  1000 
selects  the  contents  of  locations  1000  and  1001.  'Count'  is 
used  Instead  of  'length'  to  avoid  the  problem  of  determining 
units  the  length  should  be  denominated  in  (octets,  words, 
etc.)  .  The  size  and  type  of  the  unit  will  vary  depending  on 
the  address  space  selected  by  the  target  start  address.  The 
target  should  reply  with  an  error  (if  it  is  able  to 
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determine  in  advance  of  a  transfer)  if  the  inclusive  rjinge 
of  addresses  specified  by  the  start  address  and  the  count 
contains  an  illegal  ot  nonexistent  address. 


6.3  READJDATA  Response 

Ihe  target  uses  the  READ_PATA  response  to  transmit  data 
requested  by  a  host  READ  command.  One  or  more  READ_PATA 
responses  may  be  needed  to  fulfill  a  given  READ  command, 
depending  on  the  size  of  the  data  block  requested  and  the 
transport  layer  message  size  limits.  Each  READJDATA  response 
gives  the  target  starting  address  of  its  segment  of  data.  If  the 
response  contains  an  odd  number  of  data  octets,  the  target  ends 
the  response  witli  a  null  octet. 
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0  ,  0  0  1  1 
0123456789012345 

y - + - ^ 

I  Command  Length  | 


1  I  DATA-TRANSFER 


READJ5ATA 


Target 

Start 

Address 


Data  Octet 


Data  Octet 


n  I  Data  Octet  )  Data  or  Null 


DATA  Response  Format 
Figure  28 


READJDATA  FIELDS: 

Command  Length 

The  command  length  gives  the  number  of  octets  in  the 
command,  including  data  octets,  but  excluding  the  padding 
octet,  if  any.  Ihe  host  can  calculate  the  length  of  the 
data  by  subtracting  the  header  length  from  the  command 
length.  Since  the  target  address  may  be  either  three  words 
(short  format)  or  five  words  (long  format) ,  the  address  mode 
must  be  checked  to  determine  which  is  being  used. 

Target  Start  Address 

This  is  the  starting  addiess  of  the  data  segment  in  this 
message.  Ihe  host  may  infer  the  length  of  the  data  from  the 
command  length.  The  address  format  (short  or  long)  is  the 
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I 

same  as  on  the  initial  READ  command. 

Data  Octets 

Octets  of  data  from  the  target.  Data  are  packed  according 
to  the  packing  convention  described  above.  Ends  with  a  null 
octet  if  there  are  an  odd  number  of  data  octets. 


6.4  READJDONE  Reply 

The  target  sends  a  READJDONE  reply  to  the  host  after  it  has 
finished  transferring  the  data  requested  by  a  READ  command. 
READ_PONE  specifies  the  sequence  number  of  the  READ  command. 


0  0  0  1  1 
0123456789012345 
^ - - + 

0  I  6  I 

+  - - - ^ 

1  I  L'ATA^IRANSFER  |  READJDONE  | 

+ - + - ^ 

2  I  READ  Sequence  Number  I 

- - + - 4 


RE^DJX5NE  Reply  Format 
Figure  29 


READJX)NE  FIELDS: 

READ  Sequence  Number 

The  sequence  number  of  the  READ  command  this  is  a  reply  to. 
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6 . 5  MOVE  Cossnand 

The  MOVE  command  is  sent  by  the  host  to  move  a  block  of  data 
from  the  target  to  a  specified  destination.  The  destination 
address  may  specify  a  location  in  the  target,  in  the  host,  or  in 
another  target  (for  loading  one  target  from  another)  .  The  data 
is  specified  by  a  target  starting  address  and  an  address  unit 
count.  The  target  sends  an  ERROR  reply  if  the  starting  address 
is  illegal,  if  the  ending  address  confuted  from  the  sum  of  the 
start  and  the  count  is  illegal,  or  if  holes  are  encountered  in 
the  middle  of  the  range.  If  the  MOVE  destination  is  off -target, 
the  target  moves  the  data  in  one  or  MOVE_PATAs.  Other  commands 
arriving  at  the  target  during  the  transfer  should  be  processed  in 
a  timely  fashion,  particularly  the  ABORT  command.  When  the  data 
has  been  moved,  the  target  sends  a  MOVEJX)NE  to  the  host. 
However,  a  MOVE  within  a  breakpoint  will  not  generate  a 
MOVEJX)NE. 

A  p^V’E  with  a  host  destination  differs  from  a  READ  in  that 
it  contains  a  host  address.  This  field  is  specified  by  the  host 
in  the  MOVE  command  and  copied  by  the  target  into  the  responding 
M0VE_J3ATA(s)  .  The  address  may  be  used  by  the  host  to 
differentiate  data  returned  from  multiple  MOVE  requests.  This 
information  may  be  useful  in  breakpoints,  in  multi -window 
debugging  and  in  communication  with  targets  with  multiple 
processors.  For  exanple,  the  host  sends  the  MOVE  command  to  the 
target  to  be  executed  during  a  breakpoint.  The  ID  field  in 
the  host  address  mig^t  be  an  index  into  a  host  brea)qx>int  table. 
Vfhen  the  breakpoint  executes,  the  host  would  use  the  ID  to 
associate  the  returning  MOVEjiATA  with  this  brea)q>oint. 
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! 

1 

MOVE  Command  Format 
Figure  30 


MOVE  FIELDS: 

Source  Start  Address 

The  starting  address  of  the  requested  block  of  target  data. 
An  illegal  address  type  will  g^erate  an  error  reply. 

Address  Unit  Count 

The  count  of  the  number  of  target  indivisibly* addressable 
units  to  be  transferred.  For  exanple,  if  the  address  space 
is  PHYS^MACRO,  a  count  of  two  and  a  start  address  of  1000 
selects  tlie  contents  of  locations  1000  and  1001.  'Count'  is 
used  instead  of  'length'  to  avoid  the  problem  of  determining 
units  the  length  should  be  denominated  in  (octets,  words. 
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etc.)  .  Hie  size  and  type  of  the  unit  will  vary  depending  on 
the  address  space  selected  by  the  target  start  address.  The 
target  should  reply  with  an  error  (if  it  is  able  to 
determine  in  advance  of  a  trans.'ar)  if  the  inclusive  range 
of  addresses  specified  by  the  start  address  and  the  count 
contains  an  illegal  or  nonexistent  address. 

Destination  Address 

The  destination  of  the  MOVE.  If  the  address  space  is  on  the 
target,  the  address  unit  size  should  agree  with  that  of  the 
source  address  space.  If  the  address  mode  is  HOST,  tlie 
values  and  Interpretations  of  the  remaining  address  fields 
are  arbitrary,  and  are  determined  by  the  host 
Inplementation .  For  exanple,  the  mode  argument  mic^it 
^^ecify  a  table  (brealqjoint,  debugging  window,  etc.)  and  the 
ID  field  an  index  into  the  table. 


6.6  MOVEJDATA  Response 

The  target  uses  the  MOVE_pATA  responses  to  transmit  data 
requested  by  a  host  MOVT!  command .  One  or  more  MOVE.  J)ATA 
responses  may  be  needed  to  fulfill  a  given  MOVE  command, 
depending  on  the  size  of  the  data  block  requested  and  the 
transport  layer  message  size  limits.  Each  MOVEJDATA  response 
gives  the  target  starting  address  of  its  segment  of  data.  If  the 
response  contains  an  odd  number  of  data  octets,  the  target  should 
end  the  response  with  a  null  octet. 
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0  0  0  1  1 
0i23456789012345 

+ - - - + - 4. 

I  Coionand  Length  | 

+ - 4. - 4. 


I  DATA^TRANSFER  |  M0VEJ3ATA  | 


-- 

Source 

Start 

Address 

-- 

Destination 

.  . 

Start 

Address 

- 4. - 

8 


I  Data  Octet  |  Data  Occet  j 

4. - - - 4. - 4. 

* 


* 

* 

4. - ...... - 4----T. - - - 4. 

n  I  Data  Octet  |  Data  or  Null  { 

4.... - .......4. — .  —  ... - 4. 


I  Data 


I 

I 

4.. 4. 


M0VE_J)ATA  Response  Format 
Figure  31 


MOVEJDATA  FIELDS: 

Command  Length 

The  command  length  gives  the  number  of  octets  in  the 
command,  including  data  octets,  but  excluding  the  padding 
octet,  if  any. 

Source  Start  Address 

This  is  the  starting  address  of  the  data  segssent  in  this 
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message.  Ihe  host  may  infer  length  of  the  data  from  the 
command  length. 

Destination  Address 

The  destination  address  copied  from  the  MOVE  command  that 
initiated  this  transfer.  In  the  case  of  HOST  MOVEs,  this  is 
used  by  the  host  to  identify  the  source  of  the  data. 

Data  Octets 

Octets  of  data  from  the  target.  Data  are  packed  according 
to  the  packing  convention  described  above.  Ends  with  a  null 
octet  if  there  are  an  odd  nuznber  of  data  octets. 


6.7  MOVEJDONE  Reply 

The  target  sends  a  MOVEJXDNE  reply  to  the  host  after  it  has 
finished  transferring  the  data  requested  by  a  MOVE  command. 
MOVEJX)NE  specifies  the  sequence  number  of  the  MOVE  command. 


0  0  0  1  1 
0123  4  56789012345 

+ - - - 4.^.... - + 

0  I  6  ! 

- + - .4, 

1  I  DATA^TRANSFER  j  MOVEJDONE  | 

4. - 4. - 4, 

2  I  MOVE  Sequence  Number  | 

+ - - 


M0VFJX)NE  Reply  Format 
Figure  32 


MOVEJ)ONE  FIELDS: 

MOVE  Sequence  Number 

The  sequence  number  of  the  MOVE  command  this  is  a  reply  to. 
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6.8  REPEAT  J)ATA 

The  REPEATJ3ATA  command  is  sent  by  the  host  to  write  copies 
of  a  specified  pattern  into  the  target.  This  provides  an 
efficient  way  of  zeroing  target  memory  and  initializing  target 
data  structures.  The  conanand  jspecifies  the  target  starting 
address «  the  number  of  copies  of  the  pattern  to  be  made,  and  a 
stream  of  octets  that  constitutes  the  pattern. 

This  command  differs  from  the  other  data  transfer  commands 
in  that  the  effect  of  a  REPEATJATA  with  a  large  pattern  cannot 
be  duplicated  by  sending  the  data  in  smaller  chunks  over  several 
commands.  Therefore,  the  maximum  size  of  a  pattern  that  can  be 
copied  with  R£PEATJ}ATA  will  depend  on  the  message  size  limits  of 
the  transport  layer. 


0  0  0  1  1 
0123456789012345 

+ - 4. - 4. 

0  I  Command  Length  | 

> - + - 4 

1  I  DATA.TRANSFER  |  REPEATJ3ATA  | 

■; 
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3 

4 

6  I  Repeat  Count  | 

^ - 4, - 

7  I  Data  Octet  |  Data  Octet  j 

^ - 4. - ^ 

* 

* 

* 

♦ - —  4 - 4. 

n  I  Data  Octet  |  Data  or  Null  | 

4. - ^ - - - 4.  4,. 4, 


4. - - 

1 

-f-- 
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1 

Start 

1 

Address 

-- 

1 

4 - - 
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RJEPEATJ>ATA  Command  Format 
Figure  33 
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REPEATJ)ATA  FIELDS: 

Conanand  Length 

Iho  conanand  length  gives  the  number  of  octets  In  the 
conanand,  including  data  octets  in  the  pattern,  but  excluding 
the  padding  octet,  if  any. 

Target  Start  Address 

This  is  the  starting  address  where  the  first  copy  of  the 
pattern  should  be  written  in  tl»  target.  Successive  copies 
of  the  pattern  are  made  contiguously  starting  at  this 
address. 

Repeat  Count 

The  repeat  count  specifies  the  number  of  copies  of  the 
pattern  that  should  bci  made  in  the  target.  The  repeat  count 
should  be  greater  than  zero. 

Pattern 

The  pattern  to  be  cof^ied  into  the  target,  packed  into  a 
stream  of  octets.  Data  are  packed  according  to  the  packing 
convention  described  above.  Ends  with  a  null  octet  if  there 
are  an  odd  number  of  data  octets. 


6.9  VIRITE«MASK  Conraanci  (Optional) 

The  host  sends  a  VIRITEJiASK  comnand  to  the  target  to  write 
one  or  more  masked  values.  The  comnand  uses  an  address  to 
specify  a  target  base  location,  followed  by  one  or  more  offset- 
mask-value  triplets.  Each  triplet  gives  an  offset  ."rom  the  base, 
a  value,  and  a  mask  indicating  which  bits  in  the  location  at  the 
offset  are  to  be  changed. 

This  optional  command  is  intended  for  use  in  controlling  the 
target  by  changing  locations  in  a  table.  For  example,  it  may  be 
used  to  change  entries  in  a  target  parameter  table.  The 
operation  of  modifying  a  specified  location  with  a  masked  value 
is  intended  to  be  atomic.  In  other  words,  another  target  process 
should  not  be  able  to  access  the  location  to  be  modified  between 
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VIRITE^M^  Format 
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WRITE.MASK  FIELDS: 

CoDinand  Length 

The  comnand  length  gives  the  number  of  octets  in  the 
comnand.  The  number  of  offset*value  pairs  may  be  calculated 
from  this,  since  the  comnand  header  is  either  10  or  12 
octets  long  (short  or  long  addi'ess  format) ,  and  each 
offset'‘mask*value  triplet  is  12  octets  long. 

Target  Base  Address 

Sprx:ifies  the  tt^rget  location  to  which  the  offset  is  added 
to  yield  tlie  location  to  be  modified. 

Offset 

An  offset  to  be  added  to  the  base  to  select  a  location  to  be 
modified. 

Mask 


Specifies  which  bits  in  the  value  are  to  be  copied  into  the 
location . 

Value 

A  value  to  be  stored  at  the  jqpecified  offset  from  the  b.%se. 
TTie  set  bits  in  the  mask  determine  which  bits  in  the  value 
are  applied  to  the  location.  The  following  algorithm  will 
achieve  the  intended  result:  take  the  one*s  coqplenent  of 
the  mask  and  AND  it  with  the  location,  leaving  the  result  in 
the  location.  Then  AND  the  mask  and  the  value,  and  OR  the 
result  into  the  location. 
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CHAPTER  7 


Control  Commands 


Control  commands  are  used  to  control  the  execution  of  target 
code,  breakpoints  and  watcl^oints.  They  are  also  used  to  read 
and  report  the  state  of  these  objects.  The  object  to  be 
controlled  or  reported  on  is  specified  with  a  descriptor.  Valid 
descriptor  modes  include  PHj^_*  (for  some  commands)  PR0CESS_C0DE, 
BREAKPOINT  and  WATCHPOINT.  Control  commands  which  change  the 
state  of  the  target  are  START,  STOP,  CONTINUE  and  STEP.  REPORT 
requests  a  STATUS  report  on  a  target  object.  EXCEPTION  is  a 
spontaneous  r^ort  on  an  object,  used  to  report  asynchronous 
events  such  as  hardware  traps.  The  host  may  verify  the  action  of 
a  START,  STOP,  STEP  or  CONTINUE  command  by  following  it  with  a 
REPORT  command. 


7 , 1  START  Conmand 

The  START  comniand  is  sent  by  the  host  to  start  eocecutlon  of 
a  specified  object  In  the  target.  For  targets  which  support 
multiple  processes,  a  PROCET S..C0DE  address  specifies  the  process 
to  be  started.  Otherwise,  one  of  the  PHYS_*  modes  my  specify 
a  location  in  macro -memory  vtmre  eaecation  is  to  continue. 
Applied  to  a  breaJqpoint  or  watchpolnt,  START  sots  the  value  of 
the  object's  state  variable,  and  activates  the  breakpoint.  The 
breakpoint  counter  and  pointer  variables  are  initialized  to  zero. 
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0  0  0  1  1 
0123456789012345 


M  + 
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CCmROL 

T  * 

1 

START 

Mode 

1 

0 

-- 

ID 

Field 

Offset 

-- 

+-+ 
I  I 

+  I 


Address 


START  Coomand  Format 
Figure  35 


START  FIELDS; 
Address 


The  descriptor  specifies  the  object  to  be  started.  If  the 
mode  is  PR0CESS_C0DE«  ID  specifies  the  process  to  be 
started,  and  offset  gives  the  process  virtual  address  to 
start  at.  If  the  mode  is  PHfSj*.  execution  of  the  target  is 
continued  at  the  specified  address. 

For  modes  of  BREAKPOINT  and  ViATCHPOINT.  the  offset  specifies 
the  new  value  of  the  FSM  state  variable.  This  is  for  FSM 
breakpoints  and  vatchpoints. 
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7 . 2  STOP  Command 

The  STOP  command  is  sent  by  the  host  to  stop  execution  of  a 
specified  object  in  tVie  tar^t.  A  descriptor  specifies  the 
object.  Jelled  to  a  brealq>oint  or  watchpolnt,  STOP  deactivates 
it.  The  breaIqx)int/watcipoint  may  be  re- activated  by  issuing  a 
START  or  a  CONTINUE  command  for  it. 


C  0  0 

0123456789 
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1  CONTROL  1 
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1 

+--  ID 

1  Field 

1 

1 

+-+ 

I 

I 

I  Descriptor 

I 

I 

+-+ 


STOP  Commano  Format 
Figure  36 


STOP  FIELDS: 

Descriptor 

The  descriptor  specifies  the  object  to  be  stopped  or 
disarmed.  If  the  mode  is  PROCESS_CODE^  the  ID  specifies  the 
process  to  be  stopped. 

For  modes  of  BREAKPOINT  and  WATQIPOINT,  the  specified 
breakpoint  or  watclpoint  is  deactivated.  It  may  be  re¬ 
activated  by  a  CONTINUE  or  START  command. 
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7 . 3  CONTINUE  Connnand 

Hie  CONTINUE  connnand  is  sent  by  the  host  to  resume  execution 
of  a  specified  object  in  the  target.  A  descriptor  specifies  the 
object.  Applied  to  a  breakpoint  or  watclpoint,  CONTINUE  activates 
it. 


1  2  3  4  5  6 
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-- 
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-- 

+-+ 
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I  j  Descriptor 
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-i--  + 


CONTINUE  Command  Format 
Figure  37 


CONTINUE  FIELDS: 

Descriptor 

The  descriptor  specifies  the  object  to  be  resumed  or  armed. 
If  the  mode  is  PROCESS^CODE,  the  ID  specifies  the  process  to 
be  resumed. 

For  modes  of  BREAKPOINT  end  WATCHPOINT,  the  specified 
breakpoint  or  watclpolnt  is  armed. 


7 . 4  STEP  Command 

The  STEP  command  is  sent  by  the  host  to  the  target.  It 
requests  the  execution  of  one  Instruction  (or  appropriate 
operation)  in  the  object  specified  by  the  descriptor. 
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STEP  Command  Format 
Figure  38 


STEP  FIELDS: 

Descriptor 

Ihe  descriptor  specifies  the  object  to  be  stepped.  If  the 
mode  is  PROCESS^CODE,  the  ID  specifies  a  process. 


7.5  REPORT  Command 

The  REPORT  command  is  sent  by  the  host  to  request  a  status 
report  on  a  sp^ecified  target  object.  The  status  is  returned  in  a 
STATUS  reply. 
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0  0  0  1  1 
0123456789012345 


0  1 

10 

- + 

1 

1  1 

CONTROL 

1 

REPORT 

1 

2  r~ 

Mode 

1 

0 

1 

“  “  “  ^ 

3  1 

ID 

1 

Field 


Descriptor 


REPORT  Command  Format 
Figure  39 


REPORT  FIELDS: 

Descript nr 


The  descriptor  specifies  the  object  for  which  a  STATUS 
report  is  requested.  For  a  mode  of  PROCESS^CODE,  the  ID 
specifies  a  process.  Other  valid  modes  are  PHYS.J1ACR0,  to 
query  the  status  of  the  target  application,  and  BREAKPOINT 
and  WATCHPOINT,  to  get  the  status  of  a  breakpoint  or 
watclpoint . 


7.6  STATUS  Reply 

The  target  sends  a  STATUS  reply  in  response  to  a  REPORT 
command  from  the  host,  STATUS  gives  the  state  of  a  specified 
object.  For  exasple,  it  aiay  tell  whether  a  particular  target 
process  is  running  or  stopped. 
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STATUS  Reply  Format 
Figure  40 


STATUS  FIELDS: 

Descriptor 

The  descriptor  specifies  the  object  whose  status  is  being 
given.  If  the  mode  is  PROCESS_CODE,  then  the  ID  specifies  a 
process.  If  the  mode  is  PHyS_MACRO,  then  the  status  is  that 
of  the  target  application. 

Status 

The  status  code  describes  the  status  of  the  object.  Status 
codes  are  0=STOPPED  and  1=RUNNING.  For  breakpoints  and 
watcipoints,  STOPPED  means  disarmed  and  RUNNING  means  armed. 

Other  Data 

For  breakp>oints  and  watclpoints.  Other  Data  consists  of  a 
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16 -bit  word  giving  the  current  value  of  the  FSM  state 
variable. 


7.7  EXCEPTION  Trap 

An  EXCEPTION  is  a  spontaneous  message  sent  from  the  target 
indicating  a  target -machine  exception  associated  with  a 
particular  object.  The  object  is  specified  by  an  address. 
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EXCEPTION  Format 
Figure  41 


EXCEPTION  FIELDS; 
Address 
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The  address  specifies  the  object  the  exception  is  for. 

Type 

The  type  of  exception.  Values  are  target -dependent. 

Other  Data 

Values  are  tar get -dependent. 
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CHAPTER  6 


Management  Cooinands 


Management  comDands  are  used  to  cor^trol  resources  in  the 
target  machine.  There  are  two  kinds  of  commands ;  those  that 
interrogate  the  remote  machine  about  resources «  and  those  that 
allocate  and  free  resources.  There  are  management  commands  to 
create,  list  and  delete  brealqpoints .  All  cotmnands  have 
corresponding  replies  which  include  the  sequence  number  of  the 
request  coonand.  Failing  requests  produce  ERROR  replies. 

There  are  two  resource  allocation  commands,  CREATE  and 
DELETE,  which  create  and  delete  objects  in  the  remote  machine. 
There  are  a  number  of  listing  cosoands  for  listing  a  variety  of 
target  objects  --  breakpoints,  watchpoints,  processes,  and  names. 
The  amount  of  data  returned  by  listing  commands  may  vary  in 
length,  depending  on  the  state  of  the  target.  If  a  list  is  too 
large  to  fit  In  a  single  message,  the  target  will  send  it  in 
several  list  replies.  A  flag  in  each  reply  soecifies  whether 
more  messages  are  to  follow. 


8.1  aiEATE  Coemand 

The  CREATE  command  is  sent  from  the  host  to  the  target  to 
create  a  target  object.  If  the  CREATE  is  successful,  the  target 
retxims  a  C31EATILDCWE  reply,  which  contains  a  descriptor 
associated  with  the  CREATEd  object.  The  types  of  objects  that 
may  be  specified  in  a  CREATE  include  breai^ints,  processes, 
memory  objects  and  descriptors.  All  are  optional  except  for 
breal^ints . 
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0  0  0  1  1 
0123456789012345 

i. - - - - - > - - - ^ 

I  Con&snd  Length  | 


1  I  MAHACEMEKT 


CRFATE  I 


Create  Type 


Create  ArguBMnts 


Create 

Arguments 


CREATE  Coenand  Format 
Fi^pire  42 


CREATE  FIELDS: 


Create  Type 


The  type  of  object  to  be  created.  Argumenta  vary  with  the 
type.  Currently  defined  typmm  are  shown  in  Figure  43.  All 
are  optional  except  for  BREAKPOINT. 


Create  Type  |  Symbol 


BREAKPOINT 

WATCKPOINT 

PROCESS 

MEMORY^OBJECT 

DESCRIPTOR 


Create  Types 
Figure  43 
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Create  Arguments 

Create  arguments  depend  on  the  type  of  object  being  created. 
The  formats  for  each  type  of  object  are  described  below. 
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1 

CB£ATE  BREAKPOIKT  Format 
Figure  44 


BREAKPOIJfT  and  WATCHPOINT 

The  format  is  the  same  for  CREATE  BREAKPOINT  and  CREATE 
WATCHPOINT.  in  the  following  discussion,  ‘breakpoint'  may 
be  taken  to  mear;  oither  breakpoint  or  watchpoint. 

The  address  is  the  location  where  rhe  breaiq;x>int  is  to  be 
set.  In  the  case  of  watchpoints  it  is  the  locatioti  to  be 
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watched.  Valid  modes  are  any  PHYS_*  mode  that  addresses 
macro -meincr/,  F?CCESSjCODE  for  breakpoints  and  PROCESSJDATA 
for  watchpoints . 

'Maximum  states*  is  the  number  of  states  the  finite  state 
machine  for  this  brealq>olnt  will  have.  A  value  of  zero 
Indicates  a  default  break^int,  for  targets  which  do  not 
implement  finite  state  machine  (FSM)  breakpoints.  A  default 
brealqaoint  is  the  same  as  rm  FSM  with  one  state  consisting 
of  a  STOP  and  a  RPi^ORT  command  for  the  process  containing 
the  brealqxjint. 

’Maximum  size'  is  the  total  size,  in  octets,  of  the 
brealqjoint  data  to  be  sent  via  subsequent  HREAKPOINTJ)ATA 
commands.  This  is  the  size  of  the  data  only,  and  does  not 
include  the  LDP  command  headers  and  brealgpoint  descriptors. 

'Maximum  local  variables'  is  the  number  of  32-blt  longs  to 
reserve  for  local  variables  for  this  breakpoint.  Normally 
this  value  will  be  zero. 

PROCESS 

Creates  a  new  process.  Arguments  are  target -dependent . 
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0  0  0  1  1 
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4 - 4 - 4  4-4 


CREATE  MEMORY^OBJECT  Format 
Figure  45 


MEMORY.OBJECT 

Creates  an  object  of  size  Object  Size,  with  the  given  name. 
Object  Size  is  in  target  dependent  units.  Ihe  name  may  be 
the  null  string  for  unnamed  objects.  Name  Size  gives  the 
number  of  characters  in  Object  Name,  and  must  be  even. 
Always  ends  with  a  null  octect. 

DESCRIPTOR 

Used  for  obtaining  descriptors  from  IDs  on  target  systems 
where  IDs  are  longer  than  32  bits.  There  is  a  single 
argument.  Long  ID,  whcse  length  is  target  dependent. 
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8.2  CREATE JX)NE  Reply 

Hie  target  sends  a  CREATE_PONE  rqply  to  the  host  in  response 
to  a  successful  CREATE  command.  The  rqply  contains  t±ie  sequence 
number  of  the  CREATE  request,  and  a  descriptor  for  the  object 
created.  Hiis  descriptor  is  used  by  the  host  to  specify  the 
object  in  subsequent  commands  referring  to  it.  Commands  which 
refer  to  created  objects  include  LIST«*  commands,  DELETE  and 
BEIEAKPOINTJDATA.  For  exanple,  to  delete  a  CREATEd  object,  the 
host  sends  a  DELETE  command  that  specifies  the  descriptor 
returned  by  the  CREATE J)ONE  reply. 
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CREATE_DONE  Reply  Format 
Figure  46 


CREATE JDONE  FIELDS: 

Create  Sequence  Number 

The  sequence  number  of  the  OlEATE  command  to  which  this  is 
the  reply. 

Created  ^ject  Descriptor 

A  descriptor  assigned  by  the  target  to  the  created  object. 
The  contents  of  the  descriptor  fields  are  arbitrarily 
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assigned  by  the  target  at  its  convenience.  The  host  treats 
the  descriptor  as  a  unitary  object^  used  for  referring  to 
the  created  object  in  subsequent  commajids. 


8 . 3  DELETE  Command 

The  host  sends  a  DELETE  command  to  remove  an  object  created 
by  an  earlier  CREATE  command.  The  object  to  be  deleted  is 
specified  with  a  descriptor.  The  descriptor  is  from  the 
CREATE_PONE  reply  to  the  original  CREATE  command. 


0  0  0  1  1 
0123456789012345 

+ - + - + 

0  I  10  1 

1  I  MANAGEMENT  )  DELETE  | 

4. - - - 4 - 4 

2  I  Mode  j  Mode  Argument  | 

4 - 4 - 4 

3  I  ! 

ID 

4  I  Field  I 

4 - 4 - ».-4 


DELETE  Command  Format 
Figure  47 


DELETE  FIELDS; 

Created  CSjject  Descriptor 

Specifies  the  object  to  be  deleted.  This  is  the  descriptor 
that  was  returned  by  the  target  in  the  CREATEJ[)^IE  reply  to 
the  original  CREATE  comaand. 


Created 

Object 

Descriptor 
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8 . 4  DELETEJX)NE  Reply 

The  target  sends  a  DELETEJX)NE  reply  to  the  host  in  response 
to  a  successful  DELETE  command.  The  r^ly  contains  the  sequence 
number  of  the  DELETE  request. 


0  0  0  1  1 
0123456789012345 
+ - + - + 

0  !  6  1 

- - + - + 

1  I  ^  ANAGEMENT  |  DELETELPONE  | 

+ - - 

2  I  Delete  Sequence  Number  | 

+ - - 


DELETEJDONE  Reply  Format 
Figure  48 


DELETE^NT.  FIELDS; 

Request  Sequence  Number 

The  sequence  number  of  the  DELETE  conanand  to  which  this  is 
the  reply. 


8.5  LIST^DRESSES  Conanand 

The  host  sends  a  LIST,ADDRESSES  command  to  reque:st  a  list  of 
valid  address  ranges  for  a  spiKiified  object.  The  object  is  given 
by  a  descriptor.  Typical  objects  are  a  target  proces.*$.  or  the 
target  physical  machine.  The  target  responds  with  an 
ADDRESS^,.IST  reply.  This  command  is  used  for  obtaining  the  size 
of  dynamic  address  spaces  and  for  determining  dump  ranges. 
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0 

0  1  2  3  4  5  6 

0  0  1  1 
789012345 

!  ! 

1  MANAGEMEI^ 

I  LISTJ0DRESSESI 

1  Mode 

1  Mode  Argument  | 

1 

1 

1 

•f-- 

1 

! 

ID  — *■ 

Field  1 

+-+ 

I 

I  Object 
I  Descriptor 


LIST..>DDR£SS£S  CoBinand  Format 
Figure  49 


LISTJVDDRESSES  FIELDS: 


Object  Descriptor 

^trifles  the  object  whose  address  ranges  are  to  be  listed. 
Valid  modes  Include  PHfS^MACRO,  PH^SJ^ICRO,  PR0CESS_C(»E, 
and  PROCESS  JIATA. 


8.6  ADDRESS JLIST  Reply 

The  target  sends  an  ADDRESS  JLIST  reply  to  the  host  in 
response  to  a  successful  LIST^ADISIESSES  command.  The  reply 
contains  the  sequence  number  of  the  LIST.>DDRESSES  request,  the 
descriptor  of  the  object  being  listed,  and  a  list  of  the  valid 
address  ranges  within  the  object. 
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+ 

0  i 


♦ 

2  I 

+ 

3  ! 
♦ 

4  I 

♦ 

5  I 

♦ 

6  I 

♦ 

7  I 

-f 

0  I 

♦ 

9  I 

10| 


0  0  0  1 
012345678901234 

1 

5 

Couimand  Length 

1 

MANACE^Orr  1  ADDRESS^IST 

1 

List  Sequence  Nuiober 

1 

Flags  |M|  Item  Count 

1 

1 

Descriptor 

1 

1 

1 

First  Address 

1 

1 

▲ 

j  First 

1  Address 

1  Range 

1 

^ 

1 

Last  Address 

1 

1 

1 

1 

1 

* 

•  •  ▼ 

▼  ▼ 

■V 

* 

* 

»  A 

First  Address 

^  “ 

1 

1 

w  w  ▲ 

1 

1  Last 
j  Address 
1  Range 

1 

▼ 

1 

--  Last  Address 

1 

--•f 

1 

1 

1 

1 

♦  -4- 

AIXSIESSJLIST  R«ply  Foraat 
Figure  50 
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ADDRESS J.IST  FIELDS: 
List  Sequence  Nuznber 


Hie  sequence  number  of  the  LISX«ADDRESSES  command  to  which 
this  is  the  reply. 


Flags 


If  M=l«  the  address  list  is  continued  in  one  or  more 
subsequent  ADDRESSJilST  replies.  If  M=0,  this  is  the  final 
ADDRESS_LIST. 


Item  Count 


The  number  of  address  ranges  described  in  this  command. 


Descriptor 


The  descriptor  of  the  object  being  listed. 


Address  Range 


Each  address  range  is  composed  of  a  pair  of  32 'bit  addresses 
which  give  the  first  and  last  addresses  of  the  range.  If 
there  are  'holes'  in  the  address  space  of  the  object,  then 
multiple  address  ranges  will  be  used  to  describe  the  valid 
address  space. 


8.7  LIST^BREAKPOIKTS  Command 

The  host  sends  a  LIST.BREAKPOINTS  comnand  to  request  a  list 
of  all  brealq>olnts  associated  with  the  current  connection.  The 
target  ri^lles  with  BREAKPOINTJLIST. 
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0  0  0  1  1 
0123456789012345 

+ - 4 - 4 

0  I  4  I 

4 - 4 - 4 

1  I  MANAGEMENT  jLIST^BREAKPOINIS 

4 - 4 - .....4 


LIST^REAKPOINTS  Coomand  Format 
Figure  51 


8.8  BREAKPOINTJ.IST  Rfply 

Ihe  target  sends  a  BREAKPOINT^!  ST  reply  to  the  host  in 
response  to  a  LIST..BREAKPOINTS  coomand.  The  reply  contains  the 
sequence  number  of  the  LIST..BREAKPOINTS  request,  and  a  list  of 
all  breakpoints  associated  with  the  current  connection.  The 
descriptor  and  address  of  each  breakpoint  are  listed. 
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0 

0 

0  0  1 

1234567890123 

1 

4  5 

0  1 

Command  Length 

1 

1  1 

MANAGEMENT  |HREAKPOINrj:.IST| 

2  1 

List  Sequence  Number 

1 

3  ! 

Flags  jM|  Item  Count 

1 

4  1 

Mode  1  0 

•  •  •  •  ♦ 

1 

1 

5  1 
♦- 

6  1 

ID 

Field 

1 

1 

1 

1  Breakpoint 
j  Descriptor 

1 

_ 1. 

7  1 

Mode  1  Mode  Argument  | 

1 

1 

1 

h  - ^ 

CO  a* 

ID 

Field 

1 

1 

1 

1 

1  Breakpoint 
1  Address 

10 1 

lil 

+- 

Offset 

1 

_  1 

1 

1 

1 

1 

Additional 
Descr iptor - Addre: 
Pairs 


BREAXPOIFn*J.IST  Reply  Format 
Figure  52 


BREAKPOIFTTJLIST  FIELDS: 

List  Sequence  Kumber 

•n^e  sequence  number  of  the  LIST_BREAKPOI^^^S  con&end  to  which 
this  is  the  reply. 


Flags 
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If  M=l,  the  breal<polnt  list  Is  continued  in  one  or  more 
subsequent  BREAKPOINT^! ST  replies.  If  M=0,  this  is  the 
final  BREAKPOINTJLIST. 

Item  Count 

The  number  of  breakpoints  described  in  this  list. 

Breakpoint  Descriptor 

A  descriptor  assigned  by  the  target  to  this  breakpoint. 
Used  by  the  host  to  specify  this  breakpoint  in 
BREAKPOINTJ)ATA  and  DELETE  coosnands. 

Brea}qx>int  Address 

The  address  at  which  this  brealgx>int  is  set. 


8.9  LISTJPROCESSES  Coimnand 

The  host  sends  a  LIST.J’ROCESSES  coiKBand  to  request  a  list  of 
descriptors  for  all  processes  on  the  target.  The  target  replies 
witln  PROCESSJ.IST. 


0  0  0  1  1 
0123456789012345 
♦ - ♦ - ♦ 

0  I  4  I 

♦  - - - ---♦ 

1  I  MANAGEMENT  |LISTJ>ROCESSES  | 

4 - 4. - 4 


LIST.J>ROCESSES  Coennand  Format 
Figure  53 
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8 . 10  PROCESS J*IST  Reply 

The  target  sends  a  PR0C£SSJ1*IST  reply  to  the  host  in 
response  to  a  L1ST.^0C£SSES  comnand.  The  reply  contains  the 
sequence  nunber  of  the  LIST.J^OCESSES  request,  and  a  list  of  all 
processes  in  the  target.  For  each  process,  a  descriptor  and  a 
target-dependent  amount  of  process  data  are  giv^an. 


0  0  0  1  1 
0123456789012345 

4.. .......  ...... 4........ - ...-4 

0  I  CoBBand  Length  | 

4 - 4 - 4 

1  I  MANACEMEKT  |  PROCESSJLIST  ) 

4-..--...... - .4............... 4 

2  I  List  Sequence  Number  | 

4..  —  ..........4.. - ........4 

3  I  Flags  |M|  Item  Count  | 

4 - 4 - 4 

4  I  PROCESS.COOE  |  0  | 

4----... - ...4...... - - - 4 

5  I  I 

ID  — ♦ 

6  I  Field  I 

4.. ............. 4............ — 4 

7  I  Process  data  count  | 

4--. .....4.. .4 

8  I  Process  data  |  Process  data  | 

4-.--...... - --...-...-....-..4 

* 

4.-..---. - - - 4. - - 4 

n  I  Process  data  |  Process  data  | 

4-.- - 4 


Proces^ 

Descriptor 


Process 

Data 


Additional 
Descriptor -Data 
Pairs 


PROCESS JLI ST  Reply  Format 
Figure  54 
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PROCESSJ^IST  FIELDS: 

List  S«qu«nce  Number 

The  s€»quence  number  of  the  LISTJPROCESSES  confoand  to  which 
this  is  the  reply. 

Flags 

If  the  process  list  is  continued  in  one  or  more 

subsequent  PROCESSj:«lST  replies.  If  this  is  the  final 
PRCXXSS_LIST. 

Item  Count 

The  number  of  processes  described  in  this  list.  For  each 
process  there  is  a  descriptor  and  a  variable  number  of 
octets  of  process  data. 

Process  Descriptor 

A  des:.riptor  assigned  by  the  target  to  this  process.  Used 
by  th^  host  to  ^>ecify  this  PRCXIESS  in  a  DELETE  command. 

Process  Data  Count 

Number  of  octets  of  process  data  for  this  process.  Must  be 
even. 


Process  Data 

Target -dependent  information  about  this  process.  Number  of 
octets  is  given  by  the  process  data  count. 


8.11  LIST.J<AMES  Command 

The  host  sends  a  LIST..JiAMES  coomiand  to  request  a  list  of 
available  names  as  strings.  The  target  replies  with  NAKEJLIST. 
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0  0  0  1  1 
0123456789013345 


1  I  MANAGEMENT  |  L1ST.J<AMES 


LIST.J<1AM£S  Comnand  Format 
Figure  55 


8.12  NAMELXIST  Reply 

The  target  sends  a  NAMEULIST  reply  to  the  host  in  response 
to  a  L1ST.J1AMFS  c^omand.  The  reply  contains  the  sequence  number 
f  the  L1ST.JIAMES  request,  and  a  list  of  all  target  names,  as 
trings . 


Page  85 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1985 


RFC-909 


July  1984 


0  0  0  1  1 
0123456789012345 
+ - + - + 

0  j  CoEsnsnd.  Length*  j 

+ - + - + 

1  I  MANAGEMENT  \  NAME_1.IST  | 

+ - + - + 

2  I  List  Sequence  Nuinber  | 

+ - + - + 

3  I  Flags  |Mj  ItC5»  Count  | 

+ - - + - + 

4  I  Name  Size  ) 

+ - ^ - + 

5  1  Name  Char  |  Name  Char  | 


+ - + 

* 

* 

* 

+ - — + 

n  ]  0  or  Name  Char| 
+ - + 

* 

* 

* 


-+ 


0 


I 


-f 


+  -+ 


I  Name 

j  String 

1 

I 

I 

I 

I 

1  Additional 
I  Name 
j  Strings 


NAMELIST  Reply  Format 
Figure  56 


NAMEJLIST  FIELDS: 

List  Sequence  Number 

The  sequence  number  of  the  LISTJIAMES  command  tc  which  this 
is  the  reply. 
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Flags 


If  M=l,  the  name  list  is  continued  in  one  or  more  subsequent 
NAMEJ.IST  replies.  If  M=0,  this  is  the  final  NAMEJi^IST. 

Item  Count 

The  number  of  name  strings  in  this  list.  Each  name  string 
consists  of  a  character  count  and  a  null -terminated  string 
of  characters. 

Name  Size 

The  number  of  octets  in  this  name  string.  Must  be  even. 

Name  Characters 

A  string  of  octets  composing  the  name.  Ends  with  a  null 
octet.  The  number  of  characters  must  be  even,  so  if  the 
terminating  null  comes  on  an  odd  octet,  another  null  is 
appended. 


8.13  GETJPHYS.ADDR  Command 

The  host  sends  a  GET_PHYS.^DR  command  to  convert  an  address 
into  physical  form.  Tha  target  returns  the  physical  address  in  a 
G0T^HYS.^DR  reply.  For  example,  the  host  could  send  a 
GET_PHYS_ADDR  coTTmand  containing  a  register -off  set  address,  and 
the  target  would  return  the  physical  address  derived  from  this  in 
a  GOT^HYSJVDDR  reply. 
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0 

0  1  2  3  4  5  6 

0  0  1  1 
789012345 

14 

MANAGEMENT 

'T 

1  GET J>HyS^DR 

Mode 

1  Mode  Argument 

... 

ID 

Field 

Offset 

- 

4--  + 


Address 


+-+ 


GET_PHyS_ADDR  Command  Format 
Figure  57 


GET.JWS.ADDR  FIELDS: 

Address 

The  address  to  be  converted  to  a  physical  address.  The  mode 
may  be  one  of  PHySJ^G.OFFSET,  PH^SJIEG^INDIRECT. 
PHl'S.MACRO.PTR,  any  OBJECT.*  mode,  and  any  PROCESS.*  mode 
except  for  PR0CESS3EG. 


8 . 14  G0T.PHyS^DR  Rqply 

The  target  sends  a  GQTJHYS.>DDR  reply  to  the  host  in 
response  to  a  successful  GET.PHYS.ADDR  command.  The  reply 
contains  the  sequence  number  of  the  GET.PHys.ADDR  request,  and 
the  specified  address  converted  into  a  physical  address. 
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0  0  0  1  1 
0123456789012345 


^ - + - + 

j  MANAGEMENT  1  G0T.J>ffifS^DR  | 

•f - -f - + 

I  Get  Sequence  Number  | 


3  I  PHYS.J1ACRO  I 

4 - 4- 

4  I 

4—  0 

5  I 


Offset 


Address 


OOT^PHYSJSDDR  Reply  Format 
Figure  58 


OOTJPHyS^Aim  FIELDS: 

Get  Sequence  Number 

The  sequence  number  of  the  GET.PHTS.>I^  cc^smand  to  which 
this  is  the  reply. 

Address 

The  address  resulting  from  translating  the  address  given  in 
the  GET.JWS.^ADDR  command  into  a  physical  address.  Mode  is 
always  PHfS.J1ACR0  and  ID  and  mode  argument  are  always  zero. 
Offset  gives  the  32-bit  physical  address. 
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8.15  GET_OBJECT  Command 

The  host  sends  a  GET_OBJECT  command  to  convert  a  name  string 
into  a  descriptor.  The  target  returns  the  descriptor  in  a 
GOT_OBJECT  reply.  Intended  for  use  in  finding  control  parameter 
objects . 


0  0  0  1  1 
0123456789012345 


+ - + - 4. 

0  i  Command  Length  | 

+ - + - + 

1  I  MANAGEMENT  |  GET.OBJECT  | 

+ - - + - + 

2  I  Name  Size  | 

4. - ^ - + 

3  I  Name  Char  |  Name  Char  | 

+ - + - + 

* 

* 

* 

+ - + - + 

n  I  0  or  Name  Charj  0  | 

+ - + - + 


+-+ 


Name 

String 


+-+ 


GET_OBJ£CT  Command  Format 
Figure  59 


GET.CBJECT  FIELDS: 

Name  String 

The  name  of  an  object. 

Name  Size 

The  number  of  octets  in  this  name  string.  Must  be  even. 

Name  Characters 

A  string  of  octets  conposing  the  name.  Ends  with  a  null 
octet.  The  number  of  characters  must  be  even,  so  if  the 
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terminating  null  comes  on  an  odd  octet,  another  null  is 
appended. 


8 . 16  GOT.OBJECT  Reply 

Ihe  target  sends  a  GOT^OBJECT  reply  to  the  host  in  response 
to  a  successful  GET^OBJECT  command.  The  r^ly  contains  the 
sequence  number  of  the  GET_OBJECT  request,  and  the  specified 
object  name  converted  into  a  descriptor. 


0  0  0  1  1 
0123456789012345 


1  I  MANAGEMENT  |  GOT.OBJECT 


2  I 

+ - 

3  I  Mode 


Get  Sequence  Number 

- ^ - 

I  Mode  Argument 


Object 

Descriptor 


G0T_0BJECT  Reply  Format 
Figure  60 


GOT^OBJECT  FIELDS: 

Get  Sequence  Number 

The  seq».ience  number  of  the  GET_OBJECT  command  to  which  this 
is  Uie  reply. 

Descript. or 
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CliAPTER  9 


oroaKpoints  and  WatcJpolnts 


Brea}qx)lnts  and  watcdpolnts  are  used  In  debugging 
applications.  Each  brealq^olnt  or  vatc^polnt  Is  associated  with 
one  debugger  connection  and  one  address.  When  a  breakpoint  or 
watcdpolnt  Is  triggered^  the  target  executes  one  or  more  commands 
associated  with  It.  A  brealqpolnt  Is  triggered  when  Its  address 
Is  executed.  A  vatctpolnt  Is  triggered  when  Its  address  Is 
modified.  The  same  mechanism  Is  used  for  structuring  breakpoint 
and  watclpoint  commands.  For  brevity's  sake,  'breakpoint'  will 
be  used  In  the  remainder  of  this  document  to  refer  to  either  a 
breakpoint  or  a  watclpolnt. 

The  commands  used  by  the  host  to  manipulate  brealgpolnts  are 
given  In  Figure  61,  In  the  order  in  which  they  are  normally  used. 
All  commands  are  sent  from  the  host  to  the  target,  and  each 
specifies  the  descriptor  of  a  breakpoint. 


Command 


Description 

+ — ..... - 


CREATE 

BREAKPOIKrj)ATA 

START 

STOP 

CONTINUE 

LIST^BREAKPOINTS 

REPORT 

DELETE 


Create  a  breakpoint 

Send  commands  to  be  executed  In  an 

FSM  breakpoint 

Activate  a  breakpoint,  set  state 

and  Initialize  breakpoint  variables 

Deactivate  a  breakpoint 

Activate  a  breakpoint 

List  all  breakpoints 

Report  the  status  of  a  breakpoint 

Delete  a  break:>olnt 


Commands  to  Manipulate  Break:x>ints 
Figure  61 
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There  are  two  kinds  of  breakpoints:  default  breakpoints  and 
finite  state  machine  (FSM)  brealqpolnts .  They  differ  in  their  use 
of  commands. 

Default  brealqx5ints  do  not  contain  any  commands.  When 
triggered,  a  default  brealqx>int  stops  the  target  object  (i.e., 
target  process  or  application)  it  is  located  in.  A  STATUS  report 
on  the  stopped  object  is  sent  to  the  host.  At  this  point,  the 
host  may  send  further  commands  to  d^ug  the  target. 

An  FSM  brealqjoint  has  one  or  more  conditional  command  lists, 
organized  into  a  finite  state  machine.  When  an  FSM  breakpoint  is 
created,  the  total  number  of  states  is  specified.  The  host  then 
sends  commands  (uising  BR£AKP01NT_PA7A)  to  be  associated  with  each 
state.  The  target  maintains  a  state  variable  for  the  brea]g>oint, 
\^ch  determines  which  conmand  list  will  be  executed  if  the 
brealqpoint  is  triggered.  When  the  breakpoint  is  created  its 
state  variable  is  initialized  to  zero  (zero  is  the  first  state) . 
A  breakpoint  consnand,  SET..STATE,  may  be  used  within  a  brealgx>int 
to  change  the  value  of  the  state  variable.  A  REPCSIT  command 
applied  to  a  brealqpoint  descriptor  returns  its  address,  whether 
it  is  armed  or  disarmed,  and  the  value  of  its  state  variable. 

Commands  valid  in  breal^ints  include  all  Inplemented  data 
transfer  and  control  commands,  a  set  of  conditional  coDjmands,  and 
a  set  of  breakpoint  commands.  The  conditional  commands  and  the 
breakpoint  commands  act  on  a  set  of  local  brealqpoint  variables. 
The  breakpoint  variables  consist  of  the  state  variai*!©,  a 
counter,  and  two  pointer  variables.  The  conditional  commands 
control  the  execution  of  breakpoint  command  lists  based  on  the 
contents  of  one  of  the  breakpoint  variables.  The  breakpoint 
commands  are  used  to  set  the  value  of  the  brealqpoint  variables: 
SET^STATE  sets  the  state  'Variable,  SETJ?TR  sets  one  of  the 
pointer  variables,  and  INC.CCXJNT  increments  the  brealqpoint 
counter.  There  may  be  implementation  restrictions  on  the  number 
of  breakpoints,  the  number  of  states,  the  number  of  conditions, 
and  the  size  of  the  command  lists.  Managemcmt  commands  and 
protocol  commands  are  forbidden  in  breakpoints. 

In  FSM  breakpoints,  the  execution  of  commands  is  controlled 
as  follo%».  When  a  brealqpoint  is  triggered,  the  breakpoint's 
state  variable  selects  a  particular  state.  One  or  more 
conditional  command  lists  is  associated  with  this  state.  A 
conditional  coomand  list  consists  of  a  list  of  conditions 
followed  by  a  list  of  conmands  which  are  executed  if  the 
condition  list  is  satisfied.  The  debugger  starts  a  breakpoint  by 
executing  the  first  of  these  lists.  If  the  condition  list  is 
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satisfied,  the  debugger  executes  the  associated  connand  list  and 
leaves  the  brealgjoint.  If  the  condition  list  fails,  the  debugger 
^ips  to  the  next  conditional  command  list.  This  process 
continues  until  the  debugger  either  encounters  a  successful 
condition  list,  or  exhausts  all  the  conditional  conmand  lists  for 
the  state.  The  relationship  of  commands,  lists  and  states  is 
shown  in  Figure  62  (IFs,  THENs  and  ELSEs  are  used  below  to 
clarify  the  logical  structure  within  a  state;  they  are  not  part 
of  the  protocol) . 


State  0 

IF  <conditlon  list  0> 

THEN  <conmand  list  0> 

ELSE  IF  <conditlon  list  1> 
THEN  <coiiinand  list  1> 

* 

* 

* 

ELSE  IF  <condition  list  n> 
THEN  <coiiiaand  list  n> 

ELSE  <exit> 

State  n 


Breaiq>oint  Conditional  Coanand  Lists 
Figure  62 


9 . 1  BREAKPOINTJATA  Command 

BRJEAKPOINTJDATA  is  a  data  transfer  cocBiand  used  by  the  host 
to  send  commands  to  bo  executed  In  breakpoints  and  watchpoints. 
The  command  specifies  the  descriptor  of  the  breakpoint  or 
watchpoint,  and  a  stream  of  commands  to  be  appended  to  the  end  of 
the  breaJqpoint's  cooaand  list.  BREAKPOINT.DATA  is  applied 
sequentially  to  successive  breakpoint  states,  and  successive 
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connnand  lists  within  each  state.  Multiple  BREAKPOINTJDATAs  may 
be  sent  for  a  given  brealqpolnt.  Breaks  between  BREAKPOINT_PATA 
commands  may  occur  anywhere  within  the  data  stream,  i  /en  within 
Individual  commands  In  the  data.  Sufficient  space  to  store  the 
data  must  have  been  allocated  by  the  maximum  size  field  in  the 
CREATE  BREAKPOINT/WATCHPOINT  command. 


0  0  0  1  1 
0123456789012345 


Command  Length 


1  I  DATAJIRANSFER  |  BREAKPOINTJDATA  | 


2  I  Mode 


I  Mode  Argument  | 

.4. - 4. 


ID 

Field 


I  Data 


I  Data  or  0  |  | 

.4-. -------------4.  4.-4, 


Brealqpolnt  or 

Watch(x>lnt 

Descriptor 


BREAKPOIWTJIATA  Command  Format 
Figure  63 


BREAKPOINTJIATA  FIELDS; 


Command  Length 

Total  length  of  this  command  In  octets, 
excluding  the  final  padding  octet.  If  any. 


Including  data. 


A  stream  of  data  to  be  appended  to  the  data  for  this 
breakpoint  or  watcbpolnt.  This  stream  has  the  form  of  one 
or  more  states,  each  containing  one  or  more  conditional 
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command  lists.  The  first  BR£AKPOINT..J)ATA  command  sent  for  a 
brea}<point  contains  data  starting  with  state  zero.  The  data 
for  each  state  starts  with  the  state  size.  A  conditional 
command  list  is  coaposed  of  two  parts i  a  condition  list,  and 
a  command  list.  Each  list  begins  with  a  word  that  gives  its 
size  in  octets. 


<state  0  size> 

<condition  list  0  size>  <condition  list  0> 

<coiiinand  list  0  8ize>  <cooinand  list  0> 

* 

* 

* 

<condition  list  n  size>  <condition  list  n> 
<coiiittand  list  n  size>  <coiiBnand  list  n> 
<8tate  1  size> 

<etc> 

* 


<state  n  8ize> 


Breal^int  Data  Stream  Format 
Figure  64 
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Sizes 


All  sizes  are  stored  in  16-bit  words,  and  include  their  own 
length.  The  state  size  gives  the  total  number  of  octets  of 
breakpoint  data  for  the  state.  The  condition  list  size 
gives  the  total  octets  of  brea}g>oint  data  for  the  following 
condition  list.  A  condition  list  size  of  2  indicates  an 
eopty  condition  list:  in  this  case  the  following  coisnand 
list  is  executed  unconditionally.  The  command  list  size 
gives  the  total  octets  of  brealqpoint  data  for  the  following 
command  list. 


Lists 


Condition  and  command  lists  come  in  pairs.  When  the 
breakpoint  occurs,  the  condition  list  controls  whether  the 
following  coomand  list  shoiild  be  executed.  A  condition  list 
consists  of  one  or  more  coonands  from  the  CONDITION  command 
class.  A  command  list  consists  one  or  more  LDP  commands. 
Valid  comnands  are  any  coamiands  from  the  BREAKPOINT, 
DATA.TRANSFER  or  CONTROL  connand  classes. 
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CHAPTER  10 

Conditional  C^omnands 


Conditional  comnands  are  used  in  brealqpoints  to  control  the 
execution  of  brealqpoint  coonands.  One  or  more  conditions  in 
sequence  form  a  condition  list.  If  a  condition  list  is  satisfied 
(evaluates  to  TRUE) «  the  breakpoint  command  list  isnediately 
following  it  is  executed.  (See  Breakpoints  and  Watchpoints, 
above,  for  a  discussion  of  the  logic  flow  in  conditional/coainand 
listw.)  Conditional  comnands  perform  tests  on  local  breakpoint 
variables,  and  other  locations.  Each  condition  er/aluates  to 
either  IRUE  or  FALSE.  Figure  65  contains  a  sumnary  of 
conditional  comnands: 


Comnand 


Description 

- - - 


CHANGED  <loc> 

COMPARE  <locl>  <maak>  <loc2> 
COUNT^CFQ  I  GT  j  LT]  <value> 
TEST  <loc>  <inask>  <value> 


Determine  if  a  location  has  changed 
Compare  two  locations,  using  a  mask 
Conors  the  counter  to  a  value 
Compare  a  location  to  a  value 


Conditional  Comnand  Sumnary 
Figure  65 


The  rules  for  forming  and  evaluating  condition  lists  are: 


o  consecutive  conditions  have  an  implicit  logical  AND  between 
thsm.  A  seq^4ence  of  such  conditions  is  called  an  'andLliat*. 
andLlists  are  delimited  by  an  OP  comnand  and  by  the  end  of 
the  condition  list. 

o  the  brea)qx)int  OR  comnand  may  be  inserted  between  any  pair  of 
conditions 

o  AND  takes  precedence  over  OR 

o  nested  condition  lists  are  not  supported.  A  condition  list 
is  sisply  one  or  more  ancL lists,  separated  by  ORjs. 
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o  the  condition  list  is  evaluated  in  sequence  until  either  a 
TRUE  ancLlist  is  found  (condition  list  <-  TRUE) ,  or  the  end 
of  the  condition  list  is  reached  (condition  list  <-  FALSE)  . 
An  and^list  is  TRUE  if  all  its  conditions  are  TRUE. 

The  distillation  o^  «hese  rules  into  BNF  is: 


<condition«l  ist> 

<and^list> 

<condition> 


=  <andLlist>  [OR  <andLlist>] * 

=  <condition>  [AND  <condition>] * 

=  CHANGED  I  COMPARE  I  COUNT  I  TEST 


vhere:  OR  is  a  breakpoint  command 

AND  is  inplicit  for  any  pair  of  consecutive  conditions 

For  example,  the  following  condition  list,  with  one  command  per 
line, 

COUNT_EQ  1 
OR 

COUNT_GT  10 
C0UNTj:.T  20 

evaluates  to: 

(COUNT  =  1)  OR  (COUNT  >  10  AND  COUNT  <  20) 

and  will  cause  the  command  list  that  follows  it  to  be  executed  if 
the  counter  is  equal  to  one,  or  is  between  10  and  20. 


Condition  Command  Format 


Condition  commands  start  with  the  standard  four -octet 
command  header.  The  hi^-order  bit  of  the  command  type  byte  is 
used  as  a  negate  flag:  if  this  bit  is  set,  the  boolean  value  of 
the  condition  is  negated.  This  flag  applies  to  one  condition 
only,  and  not  to  other  conditions  in  the  condition  list. 
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0  0  0  1  1 
0123456789012345 

+ - + - + 

0  I  Command  Length  | 

+ - + - + 

1  1  CONDITION  |N|  Type  j 
+ - + - + 


Condition  Command  Header 
Figure  66 


10.2  COUNT  Conditions 

The  COUNT  conditions  (C0UNT_FQ,  COUNT^GT  and  COUNTJ^T)  are 
used  to  compare  the  breakpoint  counter  to  a  specified  value.  Ihe 
counter  is  set  to  zero  when  the  breaI^>oint  is  STARTed,  and  is 
incremented  by  the  INC_C0UNT  breakpoint  command.  The  format  is 
the  same  for  the  COUNTJEQ,  COUNT.GT  and  C0UNTj:-T  conditions. 


0  0  0  1  1 
0123456789012345 


1  I  CONDITION  |N!  Type 


Value 


COUNT  Condition  Format 
Figure  67 


COUNT^*  Condition  FIELDS: 
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Type 


One  of  COUNTJEQ,  COUNT JjT  and  COUNT^GT.  The  condition  is 
TRUE  if  the  breal^>oint  counter  is  [EQ  |  LT  |  GT]  the 
specified  value. 


Value 

A  32 -bit  value  to  be  coiopared  to  the  counter. 


10.3  CHANGED  Condition 

The  CHANGH)  condition  is  TRUE  if  the  contents  of  the 
specified  location  have  changed  since  the  last  tise  this 
brealqpoint  occurred.  Only  one  location  may  be  ^^fK^ified  as  the 
object  of  CHANGED  conditions  per  breakpoint .  The  CHANGED 
condition  is  always  FALSE  the  first  time  the  breakpoint  occurs. 


0 

1 

2 

3 

4 

5 

6 


0  0  0  1  1 
0123456789012345 
+ - - - ♦ - 


I 


I  CONDITION 


14 

|Ni  a:ANGED 

-4- - -  — 


I 

♦ 

I 


Address 


•4- 


+ 


I 


CHANGED  Condition 
Figure  68 
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CHANGED  FIELDS: 


Address 


Conditional  Commands 


The  full  5-word  address  of  the  location  to  be  tested  by  the 
CHANGED  command. 


10.4  COMPARE  Condition 

The  COMPARE  condition  con^jares  two  locations  using  a  mask. 
The  condition  is  TRUE  if  (<locl>  &  <mask>)  ~  (<loc2>  &  <mask>)  . 


Page  103 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1985 


RFC-909 


July  1984 


0  0  0 
0123456789 

1  1 
0  1  2  3  4  5 

28 

-r 

CONDITION  |N| 

compare: 

Address 

1 

Mask 

-- 

Address 

2 

-- 

... 

COMPARE  Condition 
Figure  69 
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COMPARE  FIELDS: 

Address  1 
Address  2 

■Hie  5“Word  addresses  of  the  locations  to  be  compared. 


Mask 

A  32 “bit  mask  specifying  which  bits  in  the  locations  should 
be  conpared. 


10.5  TEST  Condition 

The  TEST  condition  is  used  to  compare  a  location  to  a  value, 
using  a  mask.  The  condition  is  TRUE  if  (<loc>  &  <mask>)  = 
<value> . 


! 
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0  0  0  1  1 
0123456789012345 


+ - 

°  ! 

22 

1  1  CONDITION 

|Nj  TEST 

2  i 

3  P 

Address 

4  P 

5  P 

6  j 

... 

7  1 

8  1 

Mask 

9  1 

lOi 

+ - ..... 

Value 

-- 

TEST  Condition 
Figure  70 


TEST  FIELDS: 

Address 

The  5-vord  address  of  the  location  to  be  conpared  to  the 
value . 


Mask 

A  32 -bit  mask  specifying  which  bits  in  the  location  should 
be  conpared. 

Value 


A  32-bit  value  to  compare  to  the  masked  location. 
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CHAPTER  11 

Breakpoint  Commands 

Breakpoint  Commands 

Breakpoint  commands  are  used  to  set  the  value  of  breaigpoint 
variables.  These  commands  are  only  valid  within  breai^ints  and 
watchpoints.  Ihey  are  sent  from  the  host  to  the  target  as  data 
in  BREAKPOINTJDATA  commands.  Figure  71  contains  a  summary  of 
breakpoint  commands: 

Command 

Description 

INCITEMENT  <location> 

INC^COUNT 

OR 

SETJPTR  <n>  <location> 
SET^STATE  <n> 


Increment  the  specified  location 
Increment  the  brealqjoint  counter 
OR  two  brcalqx5int  condition  lists 
Set  pointer  <n>  to  the  contents  of 
<location> 

Set  the  breakpoint  state  variable 
to  <n> 


Breal^int  Command  Summary 
Figure  71 


INCREMENT  Command 


The  INCREMENT  command  incronents  the  contents  of  a  specified 
location.  The  location  may  be  in  any  address  space  writable  from 
LDP. 


Page  109 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


RFC- 909 


July  1984 


0  0  C  1  1 

0123456789012345 


2  ! 

3  I 

4 

5 

6 


!  ! 

1  BREAKPOINT 

1  INCREMENT 

1 

I 

1 

f 

1 

1 

Address 

1 

1 

--+ 

1 

1 

1 

1 

1 

1 

1 

+ - 

- + - 

1 

1 

- 4 

INCREMENT  Conmand  Format 
Figure  72 


INCREMENT  FIELDS: 

Address 

The  full  adcL'ess  of  the  location  whose  contents  are  to  be 
lncr€stnented . 


11.2  INC_COUNT  Command 

The  INC_COUNT  command  increments  the  breaiqpoint  counter . 
There  is  one  counter  variable  for  each  breakpoint.  It  is 
Initialized  to  zero  when  the  breakpoint  is  created,  when  it  is 
amed  with  the  START  command,  and  wheriever  the  brealqpolnt  state 
changes.  The  counter  is  tested  by  the  COUNT_*  conditions. 
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Breakpoint  Commands 


0  0  0  1  1 
0123456789012345 

+ - ^ - f 

0  I  4  I 

+ - ^ - ^ 


1  I  BREAKPOINT  \  INC^COUNT  | 

^ - ^ - 4 


INC.COUNT  Connnand  Format 
Figure  73 


•V 


11.3  OR  Command 

Ihe  OR  command  delineates  two  andLllsts  In  a  breakpoint 
condition  list.  A  condition  list  Is  TRUE  If  any  of  the  OR 
separated  andLllsts  In  It  are  TRUE.  A  brea]qx>lnt  condition  list 
may  contain  zero«  one  or,  many  OR  cofonands.  See  'Condition 
Coanands'  for  an  esq^lanatlon  of  condition  lists. 


0  0  0  1  1 
0123456789012345 

4 - 4. - 4 

0  I  4  I 

4 - 4._. - 4 

1  i  BREAKPOINT  {  OR  i 
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11 . 4  SETJ>IR  Command 


The  SET.PT11  command  loads  the  specified  brea*tqx>lnt  pointer 
with  the  contents  of  a  location.  The  pointer  variables  and  the 
SET,..PTR  command  are  intended  to  provide  a  primitive  but  unlimited 
indirect  addressing  capability.  Two  addressing  modes « 
BPT..PT1C0FFSET  and  BPT^PTIdNDIRECT,  are  used  for  referencing  the 
brealqpoint  pointers.  For  exasple,  to  follow  a  linked  list,  use 
SET.J^  to  load  a  pointer  with  the  start  of  the  list,  then  use 
successive  SET^pTR  commands  with  addressing  mode  ’lETJPTK-OFFSET 
to  get  successive  elemezits. 


0  0  0  1  1 
012345678901234  5 


1  I  BREAKPOINT  |  SET.J>TR 


Pointer 


Srrj>TR  FIELDS: 


Pointer 


Address 


SET_J*TR  Command  Format 
Figure  75 


The  pointer  to  be  changed.  Allowable  values  are  0  arxl  1 


Address 
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The  full  address  of  the  location  whose  contents  are  to  be 
loaded  Into  the  given  |x>lnter  variable. 


11 . 5  SET_STATE  Command 

The  SET.STATE  comnand  sets  the  breakpoint  state  variable  to 
the  specified  value.  This  la  the  only  method  of  changing  a 
breakpoint's  state  from  within  a  breakpoint.  The  breakpoint's 
state  may  be  also  be  changed  by  a  START  command  from  the  host. 
The  state  variable  Is  Initialized  to  zero  when  the  breakpoint  Is 
created . 


0  0  0  1  1 
0123456789012345 

4 - - ^ 

0  I  6  I 

^ - ^ - ^ 

1  I  BREAKPOINT  |  SET^STATE  | 

4 - 4 - 4 

2  i  State  Value  { 


SET^STATE  Command  Fonaat 
Figure  76 


SET.STATE  FIELDS: 

State  Value 

The  new  value  for  the  breaigpoint  state  variable.  Must  not 
be  greater  than  the  maximum  state  value  specified  in  the 
CREATE  BREAKPOINT  command  that  created  this  breakpoint. 
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APPENDIX  A 


Diagram  Conventions 


Command  and  message  diagrams  are  used  in  this  document  to 
illustrate  the  format  of  these  entities.  Words  are  listed  in 
order  of  transmission  down  the  page.  The  first  word  is  word 
zero.  Bits  within  a  word  run  left  to  right,  most  significant  to 
least.  However,  following  a  convention  observed  in  other 
protocol  documents,  bits  are  nunibered  in  order  of  transmission; 
the  most  significant  bit  in  a  word  is  transmitted  first.  The  bit 
labelled  'O'  is  the  most  significant  bit. 


0  0  0  1  1 
012:5456789012345 


1  I  Most  Sig  Octet  I  Least  S.  Octet] 
+ - + - ^ 


M  =  most  significant  bit  in  word  zero, 
transmitted  first 

L  =  least  significant  bit  in  word  zero, 
transmitted  last 


Sample  Diagram 
Figure  77 
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APPENDIX  B 


Command  Summary 


Hie  following  table  lists  all  non-breakpoint  LDP  commands  in 
alphabetical  order,  with  a  brief  description  of  each. 
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Command 


ABORT 

ABORTJDONE 

ADDRESS^LIST 

BREAKPOINT  JDATA 

BREAKPOINT  JLI ST 

CONTINUE 

CREATE 

CREATE JX)NE 

DELETE 

DELETE_PONE 

EXCEPTION 

ERROR 

ERRACK 

GET.OBJECT 

GETJPHYS^DRESS 

GOT.OBJECT 

GOT^HYS^DRESS 

HELLO 

HELLO_REPLY 

LIST^DRESSES 

LIST^BREAKPOINTS 

LIST,JIAMES 

LISTJPROCZSSES 

MOVE 

MOVEJDONE 

MOVEJ)ATA 

NAME_LIST 

PROCESS^IST 

READ 

READJ)ATA 

READJX)NE 

REPEATJ)ATA 

REPORT 

START 

STATUS 

STEP 

STOP 

SYNCH 

SYNCHJIEPLY 

WRITE 

WRITE^ilASK 
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Sender 

I  Host  Target  j  Function 
+ - + - 


X 

X 

X 

X 

X 


X 

X 

X 


X 

X 

X 

X 

X 

X 


X 


X 

X 

X 

X 

X 

X 

X 

X 


X 

X 

X 


X 

X 

X 

X 


X 

X 

X 


X 

X 

X 

X 

X 

X 


X 


X 


Abort  outstanding  commands 

Acknowledge  ABORT 

Return  valid  address  ranges 

Send  breakpoint  commands 

Return  list  of  brealq^oints 

Resume  execution 

Create  target  object 

Acknowledge  CREATE 

Delete  target  object 

Acknowledge  DELETE 

Report  target  exception 

Rqport  error  with  a  host  command 

Acknowledge  ERROR 

Get  object  descriptor  from  name 

Get  address  in  physical  form 

Return  object  descriptor 

Return  physical  address 

Initiate  LDP  session 

Return  LDP  parameters 

Request  valid  address  ranges 

Request  breakpoint  list 

Request  name  list 

Request  process  list 

Read  data  from  target 

Acknowledge  MOVE  conpletlon 

Send  data  request  by  MOVE 

Return  name  list 

Return  process  list 

Read  data  from  target 

Return  data  requested  by  READ 

Acknowledge  READ  conpletion 

Write  copies  of  data 

Request  status  of  object 

Start  target  object 

Return  status  of  object 

Step  execution  of  target  object 

Stop  target  object 

Check  sequence  number 

Confirm  sequence  number 

Write  data 

Write  data  with  mask 
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APPENDIX  C 


Commands^  Responses  and  Replies 


Ihe  following  table  shows  the  relationship  between  commands, 
responses  and  replies.  Coinmar<ds  are  sent  from  the  host  to  the 
target.  Some  commands  elicit  responses  and/or  replies  from  the 
target.  Responses  and  replies  are  sent  from  the  target  to  the 
host.  The  distinction  between  them  is  that  the  target  sends  only 
one  reply  to  a  command,  but  may  send  multiple  responses . 
Responses  always  contain  data,  whereas  replies  may  or  may  not. 
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1  R^ly 

ABORT 

ABORTJXINE 

BREAKPOINT_DATA 

CONTINUE 

CREATE 

CREATEJX)NE 

DELETE 

DELEHLDONE 

GET.OBJECT 

OOT.OBJECT 

CTETJ^HYSJVDDRESS 

GOTJ*HYS^AK»ESS 

hello 

HELL03EPLY 

LISTJVDDRESSES 

ADI»ESSJLIST 

LIST_BREAKPOINTS 

HREAKPOINT_LIST 

LIST.JiAMES 

NAMEJLIST 

LISTJPROCESSES 

PROCESS J.IST 

MOVE 

M0VEJ3ATA 

MOVEJOONE 

READ 

READ_DATA 

READJXDNE 

REPEATJJATA 

REPORT 

STATUS 

START 

STEP 

STOP 

SYNCH 

SYNOLREPLY 

WRITE 

WRITEJ1ASK 

CoBmands,  Rei^nses  and  Replies 
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Glossary 


Finite  state  machine.  Commands  of  each  breakpoint  or 
watcipoint  are  implemented  as  part  of  a  finite  state 
machine.  A  list  of  breakpoint  commands  is  associated  with 
each  state.  Ihere  are  several  brealqDoint  commands  to  change 
from  one  state  to  another. 


The  'host*  in  an  LDP  session  is  the  timesharing  system  on 
which  the  user  process  runs. 


A  long  is  a  32 -bit  quantity. 


octet 


An  octet  is  an  eight -bit  quantity. 


The  Reliable  Data  Protocol  (RDP)  is  a  transport  layer 
protocol  designed  as  a  low-overhead  alternative  to  TCP.  RDP 
is  a  connection  oriented  protocol  that  provides  reliable, 
sequenced  message  delivery. 


server  process 

The  LDP  server  process  is  the  passive  participant  in  an  LDP 
session.  The  server  process  usually  resides  on  a  target 
machine  such  as  a  PAD,  PSN  or  gateway.  The  server  process 
waits  for  a  user  process  to  initiate  a  session,  and  responds 
to  commands  from  the  user  process.  In  response  to  user 
connnands,  the  server  may  perform  services  on  the  target  like 
reading  and  writing  memory  locations  or  setting  breakpoints. 
'Server'  is  sometimes  employed  as  a  shortharid  for  'server 
process' . 
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target 

Ihe  ’target'  in  an  LDP  session  is  the  PSN,  PAD  or  gateway 
that  is  being  loaded,  dumped  or  debugged  by  the  host. 
Normally,  LDP  will  be  implemented  in  the  target  as  a  server 
process.  However,  in  some  targets  with  strange 
requirements,  notably  the  Butterfly,  the  target  LDP  may  be  a 
user  process. 


user  process 


The  LDP  user  process  is  the  active  participant  in  an  LDP 
session.  The  user  process  initiates  and  terminates  the 
session  and  sends  commands  to  the  server  process  which 
control  the  session.  The  user  process  usually  resides  on  a 
timesharing  host  and  is  driven  by  a  higher- level  entity 
(e.g.,  an  application  program  like  an  interactive  debug^r)  . 
'User'  is  sometimes  eoployed  as  a  shorthand  for  'user 
process' . 


word 


A  word  is  a  sixteen-bit  quantity. 


Pago  124 


APPENDIX 


yuw 


INDEX 


ABORT  command . 

ABORTJjONE  reply . 
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CONTINUE  command . 
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ERRACK . 
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ERROR  reply . 

EXCEPTION  trap . 
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FULL-PEBUOGER . 

gateway . 

GET_OBJECT  command . . . 

GET,.J*HfS_ADDR  connnand . 

OOT.OBJECT  reply . 

GOTJPHYS^Kl  reply . 

HELLO  command . 

HELLO JiEPLY . 

host  descriptor . 

implementation . 

INC_COUNT  command . 

INCREI4ENT  command . 

internet . 

internet  protocols . 

IP . 

LDP  command  formats . 

LDP  header . 

LDP  Version . 

LIST  commands . 

LI ST.ADDRESSES  command . 
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loading . 

long  address  format . 
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offset . 

OR  command . 
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PAI) . 

pattern . 

PHifSJ^DDE^SS . 

PHifS_MACRO . 

PROCESS . 

PROCESS.CODE . 

PROCESSJLIST  reply . 

protocol  conmands . 

PSN . 

RDP . 

READ  command . 

READ  sequence  nuinber . 

READJDATA  response . 

READJDONE  r^ly . 

repeat  count . 

REPEAT JIATA  connnand . 

REPORT  command . 

sequence  number . 

session . 

SET.J’TR  command . 

SETJ5TATE  con&nand . 

short  address  format . 

START  coonand . 

STATUS  reply . 

STEP  command . 

STOP  conmand . 

SYNCH . 

SYNCH  command . 

SYNCHJtEPLY . 

system  type . 

target  start  address . 

transport . 

watcbix>lnt .  13,  57,  60,  71,  92, 

WRITE  conmand . 

WR1TE..I1ASK  coxmnand . 
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The  CSNET  Name  Server 


Marvin  Solomon,  Lawrence  H.  Landweber 
and  Donald  Neuhengen 

Umvenity  of  Wuconnn-h4adison,  Computer  Sciences  Depart- 
men:.  1210  W.  Dayton  St..  Madison.  Wl  JS706.  USA 

CSNET  is  a  project  designed  to  faciliute  electronic  data 
communication  among  academic  computer  science  depart* 
ments  and  other  groups  doing  coirputer-science  research  in  the 
United  Sut«.  CSNET  will  provide  communications  facilities 
for  electronic  mail  and  file  transfer  between  users  of  computers 
connected  to  a  variety  of  networks.  For  the  system  to  be  simple 
SuiJ  easy  tc  use,  users  must  he  able  to  identify  each  other  to  the 
system  in  a  way  that  is  natiual  to  them  and  which  does  not 
require  them  to  undentand  the  details  of  network  organizauon 
or  to  memorize  cryplk  names.  To  this  end  CSNET  is  imple¬ 
menting  a  name  server  sevice,  composed  of  programs  and  data 
reiiding  on  a  central  Service  Host  computer  and  on  individual 
member  hoau  of  CSNET.  This  paper  describes  the  architecture 
of  the  name  server  and  discusses  the  considerauoiu  that  lead  to 
its  desiyi. 

Xeywofds:  Name  saver,  directory  auistance,  computer  net¬ 
works,  database,  CSNET 
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1.  Introduction 

CSNET  is  a  project,  funded  by  the  National 
Science  Foundation,  to  develop  common  proto¬ 
cols,  software  packages,  and  an  administrative 
organization  to  facilitate  communication  among 
academic  computer  science  researchers  in  the 
United  States.  An  important  component  of  CSNET 
will  be  a  directory  service  called  the  CSNET  Name 
Server,  which  is  implemented  by  a  central  data¬ 
base  at  the  University  of  Wisconsin  and  by  soft¬ 
ware  running  at  Wisconsin  and  on  the  computers 
of  CSNET  member  institutions.  This  paper  de¬ 
scribes  the  architecture  cf  the  name  server  facility. 

In  early  stages  of  CSNET,  the  principal  use  of 
the  name  server  will  be  to  facilitate  sending  of 
electronic  mail  by  providing  directory  assistance  in 
locating  addresses  of  mail  recipients  and  aiding  in 
forwarding  mail  and  establishment  of  nicknames 
and  aliases.  It  is  on  this  aspect  of  the  name  server 
that  this  paper  focuses.  In  later  stages  of  CSNET, 
the  name  server  will  also  help  support  other  facili¬ 
ties  such  as  file  transfer  and  remote  acces:;  to 
computing  resources. 

In  the  next  section,  we  briefly  describe  CSNET 
and  explain  how  its  characteristics  have  influenced 
design  of  the  name  server.  The  structure  of  CSNET 
is  described  in  more  detail  in  [1,2]. 

We  have  designed  the  name  server  to  be  imple¬ 
mented  in  a  series  of  phases,  progressing  from 
facilities  ihat  already  exist,  through  more  and  more 
sophisticated  structures,  to  a  system  that  will  even¬ 
tually  provide  all  of  the  desired  features.  In  doing 
so,  wc  have  attempted  to  be  conservaave  in  early 
phases,  using  the  simplest  structure  that  will  fulfill 
the  immediate  needs  of  CSNET  users,  while  leav¬ 
ing  the  door  open  for  more  ambitious  enhance- 
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menis  in  the  future.  While  the  services  described 
here  will  be  implemented  with  available  CSNET 
staff  and  resources,  we  expect  the  project  to  iden¬ 
tify  several  challenging  additional  research  areas. 

Section  2  describes  CSNET  and  discusses  pro¬ 
ject  characteristics  that  have  influenced  the  name 
server  design.  Section  3  describes  name  server 
design  requirements  and  implementation  perfor¬ 
mance  goals.  Section  4  includes  definitions  of  terms 
and  an  outline  of  the  various  phases.  The  four 
phases  of  the  name  server  implementation  are 
described  in  Sections  5-8.  Section  9  briefly  ad¬ 
dresses  the  issue  of  mailing  lists,  and  Section  10 
provides  a  summary  and  compari.son  to  related 
work. 


2,  Overview  of  CSNET 

CSNET  is  a  logical  network  that  uses  communi¬ 
cations  services  provided  by  ARPANET  (3],  the 
commercial  value-added  network  Telenet,  and  a 
telephone-based  mail  relay  service  called 
PhoneNet,  based  on  the  MMDF  mail  transport 
system  (4).  Member  institutions  access  the  services 
of  CSNET  by  connecting  a  computer  ("host”)  to 
ARPANET  or  Telenet,  or  if  their  budget  is  limited 
and  they  are  willing  to  accept  reduced  service,  by 
arranging  for  their  host  to  exchange  mail  periodi¬ 
cally  with  a  PhoneNet  relay  machine  that  is  di¬ 
rectly  connected  to  ARPANET  and  Telenet. 
CSNET  will  provide  electronic  mail,  file  transfer, 
and  remote  login  (virtual  terminal)  services  to 
directly-<onnected  hosts.  PhoneNet  hosts  will  only 
have  access  to  electronic  mail  sevices.  In  addition. 
CSNET  maintains  4  Public  Host,  which  is  a  VAX 
computer  connected  to  ARPANET  and  Telenet, 
running  the  UNIX  operating  system,  end  pro¬ 
viding  mail-only  accounts  to  individuals  who  do 
not  have  access  to  any  other  CSNET  member  host. 
Users  access  the  Public  Hos«  using  terminal-to-hosi 
serMces  of  Telenet.  Although  CSNET  is  being 
subsidized  in  iis  initial  stages  by  the  National 
Science  Foundation,  it  is  expected  to  become  self- 
supporting  in  a  few  years,  with  all  members  paying 
a  fair  share  of  the  costs. 

One  of  the  challenges  of  CSNET  is  to  reconcile 
differences  between  charactensiics  of  these  com¬ 
munications  media  and  provide  users  with  as  uni¬ 
form  an  interface  as  is  possible.  ARP.ANET  pro¬ 
vides  a  high-bandwidth.  low-dclav  communica¬ 


tions  path  between  computers  connected  to  it. 
Telenet  provides  similar  (but  lower  bandwidth) 
service.  Whereas  the  cost  of  an  ARPANET  con¬ 
nection  is  fixed.  Telenet  charges  are  highly  depen¬ 
dent  on  the  amount  of  traffic.  PhoneNet  charges 
are  even  more  dependent  on  traffic,  since  the  only 
fixed  charges  are  the  cost  of  a  modem  and  a 
telephone  line.  The  remaining  charges  depend  on 
the  number  of  calls  placed  and  on  their  duration. 
However,  a  much  more  important  difference  be¬ 
tween  PhoneNet  and  direct  connection  is  delay. 
CSNET  clients  not  directly  connected  to  AR¬ 
PANET  or  Telenet  must  rely  on  periodic  exchanges 
of  mail  with  a  PhoneNet  relay  machine  for  their 
connection  to  the  network.  The  frequency  of  such 
exchanges  may  be  4S  low  as  once  daily.  We  shall 
see  that  these  wide  variations  in  delay  (from 
minutes  or  seconds  to  days)  is  an  important  con¬ 
sideration  in  the  design  of  the  name  server. 


3.  Goals 

The  name  server  facility  is  designed  to  satisfy 

the  following  service  requirements: 

1.  The  system  must  be  simple  to  use.  While  most 
CSNET  users  will  be  computer  science 
researchers,  many  will  have  little  experience 
with  computer-based  mail  systems.  User  should 
be  free  to  concentrate  on  their  research  without 
worrying  about  details  of  addressing  or  mail- 
transport  systems. 

2.  A  sender  of  mail  must  be  able  to  identify  a 
recipient  ir.  a  variety  of  convemeni  ways.  A 
user  may  refer  to  frequent  correspondents  by 
nicknames  of  his  own  choosing.  In  addition,  a 
host  may  make  available  to  its  users  aliases  for 
other  hosts  and  users. 

3.  A  receiver  of  mail  must  have  control  over  the 
information  provided  to  others  fo'  use  in  iden- 
iifvinR  him.  For  example,  he  can  supply  his  lull 
name,  organization,  location,  title,  ricknamcs. 
com.mon  nrusspeUings  of  his  name.  etc. 

4.  Correspondents  must  be  able  to  send  mail  to 
any  user  of  any  host  in  CSNET.  w about  prior 
explicit  effort  on  •..he  part  of  the  receiver,  al¬ 
though  reduced  services  will  be  available  for 
communication  with  "unregisiered"  users.  Simi¬ 
larly.  CSNET  users  musi  be  able  lo  communi- 
cate  with  others  "ouiside"  ihe  network,  in  par- 
iicular  users  on  hcs;-..  that  a.'c  the 
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Internet  address  space  but  are  not  running 
CSNET-spcdfic  software. 

5.  The  mail  system  must  never  force  a  user  to  use 
more  than  one  “mailbox”  to  receive  mail,  al¬ 
though  a  user  may  choose  to  establish  more 
than  one  mailbox  to  reflect  differing  roles.  In 
the  latter  case,  each  mailbox  may  be  thought  of 
as  representing  a  different  “virual  user". 

6.  A  user  must  be  able  to  move  his  mailbox  to  a 
different  host  computer  with  a  minimum 
amount  of  difficulty.  Senders  need  not  be  ex¬ 
plicitly  notified;  mail  will  be  automatically  for¬ 
warded. 

7.  Support  must  be  provided  for  mailing  lists. 

In  addition  to  these  service  requirements,  the  im¬ 
plementation  is  designed  to  satisfy  the  following 

additional  performance  and  utility  goals: 

1.  The  system  should  expand  gracefully  to  include 
more  member  sites,  additonal  users,  and  even 
additional  networks.  In  particular,  anyone  able 
to  send  electronic  mail  to  the  University  of 
Wisconsin  should  be  able  to  gain  access  to  at 
leut  some  of  the  name  server  services. 

2.  The  system  design  should  provide  for  phased 
Implementation  so  that  basic  services  can  be 
put  into  place  immediately,  while  more 
sophisticated  facilities  may  be  added  incremen¬ 
tally  until  all  desired  features  are  available. 

3.  Network  traffic  should  be  minimized.  Control 
messages  should  be  infrequent  and  user  text 
should  be  sent  over  the  most  efficient  route. 
Pans  of  the  name  server  rely  on  existing  net¬ 
works  and  mail  transpon  systems  for  communi¬ 
cation.  While  the  name  server  has  no  control 
over  routing  algorithms  used  by  these  facilities, 
the  cost  of  communications  must  be  taken  into 
account  m  the  design.  In  particular,  situation; 
in  which  user  text  is  sent  over  multiple  hops 
through  the  mail  system  should  be  avoided. 

4.  Tlie  system  should  continue  to  functioi».  per¬ 
haps  in  a  degraded  mode,  ii  component.^  laii. 
This  consideration  precludes  a  design  which 
makes  mail  transfer  impossible  if  the  central 
database  is  temporarily  unavailable. 

5.  Delay  between  the  submission  of  a  message  by 
a  sender  and  its  delivery  to  a  recipient  should 
be  minimized.  In  particuhr,  if  the  senier  is  on  a 
machine  that  is  oniy  periodically  connected  to 
the  test  of  CSNET  (a  PhoneNet  host),  the 
number  of  interactions  between  that  host  and 
the  rest  of  CSNET  requiicd  to  dispatch  the 


message  should  be  minimized. 

6.  The  system  should  work  with  a  minimum  of 
human  intervention,  either  on  the  part  of  users 
or  of  administrative  staff. 


4.  Definitions 

Throughout  this  paper,  we  will  be  talking  about 
users  and  hosts.  For  our  purposes  the  term  “user" 
always  refers  to  a  human  being  (and  will  not.  for 
example,  be  used  to  mean  a  “user  program").  A 
host  is  a  computer  connected  to  a  communications 
network.  Users  gain  access  to  network  facilities 
through  accounts  on  hosts.  Hosts  can  be  classified 
as  CSNET  member  hosts,  which  subscribe  to 
CSNET-defined  conventions  and  run  CSNET-pro- 
vided  software  packages,  and  other  hosts,  which 
are  capable  of  exchanging  mail  with  CSNET  mem¬ 
ber  hosts  but  do  not  necessarily  run  CSNET 
software.  There  are  also  several  CSNET-run  hosts. 
The  Service  Host,  is  a  computer  at  the  University 
of  Wisconsin  that  maintains  a  central  database 
and  programs  for  accessing  it.  PhoneNe:  relays  are 
computers  (initially  at  the  University  of  Delaware 
and  \m  Rand  Cyrporaiion)  ihai  prriodiciiiy  place 
telephone  calls  to  other  hosts  to  pick  up  and 
deliver  mail.  7^e  Public  Host  is  a  computer  at  the 
University  of  Wisconsin  that  is  run  by  CSNET  but 
otherwise  is  treated  exactly  like  any  other  CSNET 
member  host.  Hosts  may  also  classified  as 
ARPANET,  Telenet,  or  PhoneNet  hosts  depending 
on  the  principal  method  used  to  exchange  infor¬ 
mation  with  the  rest  of  CSNET.  The  name  server 
relies  for  many  of  its  functions  on  a  mail  transport 
system  which  is  a  collection  of  protocols  and  pro¬ 
grams  that  run  on  hosts  and  provide  the  mecha¬ 
nism  for  transferring  mesMges  from  sources  to 
destination^.  Users  normally  interact  with  the  mail 
transport  system  through  a  user’interface  program 

lUip/,  WTuCm  ii  *  progiiiir,  init  ifitCriCii  Witri 

for  composing,  sending,  receiving,  reading,  and 
filing  messages. 

'the  various  services  and  mevh5.”.i;.v,i  described 
in  this  paper  comprise  the  name  server  facility.  It 
is  provided  by  a  combination  of  files  and  pro- 
grifTii  residing  on  the  Service  Host  and  on  other 
CSNET  member  hosts.  The  name  server  database 
is  a  database  that  includes  directory  information 
for  registered  CSNET  users  and  hosts  and  is  dis¬ 
tributed  among  a  central  directory  database  that 
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resides  on  the  Service  Host,  per~host  tables  that 
reside  on  hosts  that  originate  mail,  and  per-user 
tables  maintained  by  local  mail  systems  on  behalf 
of  individual  users.  The  registrar  is  a  collection  of 
software  that  runs  on  the  Service  Host  and  medi¬ 
cates  access  to  and  modification  of  the  central 
directory  database. 

Users  may  access  the  name  server  database  by 
sending  messages  directly  to  the  registrar.  How¬ 
ever,  users  will  normally  compose  their  queries  by 
interacting  with  a  name  server  agent  program, 
copies  of  which  reside  on  CSNET  member  hosts. 
A  copy  of  the  agent  program  will  also  reside  on 
the  Se^ce  Host  for  the  convenience  of  users  on 
non-CSNET  hosts  who  have  virtual-terminal  access 
to  the  Service  Host.  The  agent  programs  com¬ 
municate  with  the  registrar  using  the  best  means 
available,  either  by  direct  connection  or  by  ex¬ 
change  of  messages  througn  the  mail  transport 
system.  In  the  latter  case,  there  is  necessarily  a 
large  delay,  so  users  will  receive  a  limited  level  of 
service. 

The  name  server  facility  is  specified  and  imple¬ 
mented  in  four  phases.  As  new  phases  are  imple¬ 
mented,  all  features  provided  by  earlier  phases  will 
remain  available  to  users.  Phase  0  provides  basic 
services  and  is  compatible  with  current  addressing 
and  naming  schemes  employed  in  the  DARPA 
Internet.  Phase  1  introduces  a  centralized  directory 
database  at  the  Service  Host  and  a  directory  assis¬ 
tance  service  that  users  may  access  by  exchanging 
mail  with  the  registrar  or  by  interacting  with  an 
agent  program.  In  Phase  2,  user  interaction  with 
the  directory  assistance  service  will  be  funher 
automated.  Phase  3  adds  support  for  automatic 
forwarding  of  mail  and  for  mailing  lists. 


5.  Phase  0;  Basic  Services 

Phase  0  provides  services  that  are  very  close  to 
those  currently  available  in  the  DARPA  Internet 
environment  Each  host  in  CSNET  has  an  unam¬ 
biguous  name,  such  as  ’’UWISC”,  **UDEL",  or 
“WASHINGTON".  A  site  with  a  local  network 
may  choose  to  designcte  a  particular  computer  to 
serve  a  as  a  mail  forwarder  and  assign  it  a  name 
that  designates  the  site.  Arpanet  hosts  aheady 
have  unambiguous  names.  Other  mail  transport 
systems  also  rely  on  unambiguous  names  for  hosts 
As  sites  join  CSNET.  they  will  register  their  hosts 


with  the  CSNET  administration,  which  will  certify 
that  names  are  not  duplicated.  (By  “unambiguous" 
we  mean  that  no  two  hosts  will  have  the  same 
name;  there  is  no  reason  to  prevent  a  host  from 
having  more  than  one  name.) 

Users  interact  with  the  mail  system  through 
accounts  on  hosts;  each  account  is  assigned  a  user 
name.  Each  host  will  guarantee  that  a  user  name 
unambiguously  identifies  one  user  of  that  host.  In 
other  words,  “user  name”  represents  some  name 
for  a  mailbox  that  is  printable,  is  assigned  by  a 
host  administration,  and  identifies  a  unique  user 
of  that  host.  Hence  the  pair  “user-name(3)host". 
which  we  call  a  mailbox  address,  can  be  used  to 
uniquely  identify  any  mailbox  in  CSNET, 

The  details  of  the  structure  of  mailbox  address¬ 
es  are  not  important  to  the  design  of  the  name 
server.  The  essential  features  of  a  mailbox  address 
are  that  it  be  acceptable  to  the  mail  transport 
systems  as  an  unambiguous  designation  of  the 
final  destination  of  a  message  and  that  it  be  suffi¬ 
ciently  readable  and  mnemonic  that  a  human  user 
tan  supply  it  manually  if  necessary.  The  later 
property  alllows  a  sending  user  who  does  not  have 
access  to  CSNET  software  to  bypass  the  name 
server  entirely  and  specify  the  mailbox  address 
directly.  As  we  shall  sec,  however,  more  conveni¬ 
ent  methods  will  be  available  to  users  who  use  the 
name  server. 


6.  Phase  1:  Directory  Assistance 

Phase  1  augmenu  the  basic  ficilities  described 
in  the  previous  section  with  a  "directorv  »ssis- 
tance"  service.  A  central  directory  database  on  the 
Service  Host  wiP.  contain  information  about  users. 
Each  entry  in  this  database  contains  the  address  of 
one  mailbox.  This  information  is  supplied  by  the 
owner  and  includes,  at  a  minimum  his  full  name 
and  the  name  of  his  sponsoring  organization  (e  g  . 
university  or  research  lab).  In  addition,  it  mas 
include  other  keywords  such  as  titles,  aliases,  and 
common  misspellings  of  the  usei’s  name,  postal 
address,  phone  number,  and  any  other  informa¬ 
tion  the  user  wishes  to  provide.  Registration  in  this 
database  is  entirely  voluntary  and  ii  will  be  possi¬ 
ble  to  commii.mcate  with  non-registcred  users  even 
if  their  local  site  has  not  installed  the  CSNET 
name-server  software 

The  database  is  accessed  by  transmitting  prop- 


3-850 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1985 


M.  Solomon  el  at.  /  The  CSNET  Name  Server 


ing  his  mailbox  but  including  keywords  that  match 
some  other  user,  with  the  intent  of  fooling  users 
into  sending  mail  for  tiie  other  user  to  the  per¬ 
petrator’s  mailbox.  This  ruse  would  be  particularly 
pernicious  when  lookup  is  automated  so  that  hu¬ 
man  users  don’t  normally  even  look  at  the  mailbox 
address  returned  (see  Phase  2).  The  situation  is 
comparable  (in  the  non-electronic  world)  to  Marvm 
Solomon  putting  an  advertisement  in  the  news¬ 
paper  uying  that  the  address  of  the  Pint  National 
Bank  of  Madison  is  850  Terry  Place  (Solomon’s 
home  address).  The  name  server  mechanism  can¬ 
not  prevent  such  a  fraud  without  understanding 
the  semantics  of  all  the  keywords  in  an  entry.  But 
the  injured  party,  if  he  discovers  that  mail  is  being 
misdirected,  can  query  the  central  daiaba^  to  luiw 
the  bogus  entry.  Similarly,  a  sender  might  notice 
that  certain  queries  identify  two  entries,  one  of 
which  looks  suspicious,  and  report  the  fraud.  Once 
the  fraudulent  entry  is  found,  the  culprit  can  be 
traced  as  far  as  his  host 

Authentication  is  a  difficult  but  important  area. 
Further  study  will  be  requireci  if  a  more  elaborate 
scheme  than  that  described  above  is  found  to  be 
necessary. 

6.3.  Using  the  Database 

To  access  the  central  directory,  a  query  is  de¬ 
livered  to  the  registrar  or  mailed  to  it  at  the 
address  REGISTRAR@CSNET-SH.  The  mail 
format  is  designed  to  allow  human  users  who  do 
not  have  access  to  CSNET  software  but  who  can 
send  mail  to  CSNET-SH  to  compose  the  query 
manually.  Normally,  however,  users  will  use  a 
’Nvhois”  command  of  the  agent  to  compose  such  a 
request.  The  query  will  include  lists  of  mandatory 
and  optional  keywords.  Only  entries  that  contam 
all  mandatoty  keywords  will  be  selected.  If  more 
than  one  entry  matches,  the  optional  keywords  can 
be  used  lo  select  the  entry  wnh  ihc  most  maiche*. 
or  the  registrar  may  be  instructed  to  return  only 
entries  containing  at  least  k  of  the  c^tional 
keywords. 

We  are  assuming  that  there  is  no  access  control 
on  read-only  access  to  the  database.  Registration 
voiur.*r«r%‘,  sc  «scrs  "-he  *A"iSh  sc 
anonymous  need  only  avoid  registenng.  We  could 
add  a  fac.liiy  for  restncied  enines  or  fields  in 
enines  tvisible  only  to  selected  users)  using  the 
authentication  mechanism  described  above.  We 


currently  have  no  plans  to  implement  suck  a  facil¬ 
ity,  although  there  are  some  fields  in  entries  (for 
example  the  password  field)  which  are  restricted  to 
use  by  the  registrar  itself  and  are  never  shown  to 
users. 

Keywords  can  be  parameterized  so  as  to  allow 
specification  of  pattern  matching.  Keywords  may 
also  contain  "wild  cards"  to  allow  inexact  matches. 
For  example,  the  keyword  "landwe'er"  can  be 
used  by  those  not  knowing  whether  his  name  is 
spelled  as  "landwcber”,  "landwever",  or  "land- 
webber".  Upper  and  lower  case  are  considered 
equivalent  for  matching  purposes,  but  the  entries 
will  be  displayed  to  the  requester  in  the  same  case 
as  they  were  originally  specified  at  registration. 
Tiic  requester  can  then  select  tiiC  appropnatw  entry 
(if  there  is  more  than  one  match)  ba,sed  on  other 
information  in  the  entries,  and  use  the  mailbox 
address  included  in  the  entry  to  send  mail. 

The  provision  of  mandatory  and  optional 
keywords  is  primarily  for  the  benefit  of  the  user  of 
a  PhoneNet  host,  to  maximize  the  chances  of  him 
getting  the  right  answer  on  the  first  try.  Too  few 
keywords  will  Hood  him  with  bogus  matches,  but 
too  many  mandatory  keywords  may  exclude  valid 

”^^aw  ability  tC  Jwt  *  M*ai^*** 

first  try  will  become  particularly  beneficial  in  phase 
2  (as  we  shall  see). 

Incidentally,  directory  assistance  could  be  use¬ 
ful  for  services  outside  CSNET  proper,  such  as 
looking  up  a  user's  phone  number  or  (U.S.  Post 
Office)  mailing  address. 

6.4.  Example 

Here  is  a  umple  use  of  the  name  server  in 
phase  1:  To  make  it  easier  for  others  to  find 
Marvin  Solomon,  he  issues  the  "register"  com¬ 
mand  to  the  agent,  which  engages  in  a  dialogue 
with  him  to  authenticate  his  identity  and  gather 
information  about  him.  !i  then  composes  and  en¬ 
crypts  a  message  to  REGlSTRAR(gCSNET-SH 
containing  text  something  like  this; 
rrgitier 
home 

tokMnoR^-jwiK 

mwlboi 

nam* 

Sc4onion 
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erly  formatted  queries  to  the  registrar  at  the  Service 
Host.  Users  will  not  normally  communicate  di¬ 
rectly  with  the  registrar  but  rather  with  an  agent 
program  that  formats  the  request  and  forwards  it 
to  the  Service  Host  by  a  direct  connection  or  by 
the  mail  transport  system.  However,  users  at  non- 
CSNET  computers  may  also  query  the  database 
by  mailing  requesu  directly  to  the  registrar. 

Since  we  intend  that  each  user  have  the  ability 
(and  responsibility)  to  maintain  the  database  entry 
describing  him,  certain  access  controls  must  be  in 
place  from  the  very  beginning  to  maintain  the 
integrity  of  the  database. 

6.1.  Registering 

The  user  add*  or  modifies  entries  in  the  data¬ 
base  by  interacting  with  his  local  agent  using  the 
commands  ‘’register”,  “update”,  and  “unregister”. 
The  local  agent  creates  a  message  containing  the 
user  request  to  insert,  modify  or  delete  a  central 
database  entry  and  sends  it  to  the  registrar  either 
directly  or  by  mailing  it  to  the  address  “REG- 
ISTRAR@CSNET-SH”.  The  registrar  will  parse 
me  message  and  perform  the  requested  operation. 

6.2.  Authentication 

An  important  iuue  is  authentication  of  a  user 
requesting  insertion  or  modification  of  an  entry.  A 
user  may  ^-jniy  register  himself  with  the  coopera¬ 
tion  of  a  CSNlF  memb<^  file,  which  we  may  call 
his  home  or  sponsoring  host.  When  an  organization 
joins  CSNET.  it  is  assigned  a  key  (password).  The 
administration  at  the  site  will  be  responsible  for 
controlling  its  distribution  and  for  changing  it 
when  appropriate. 

A  user  at  a  member  host  who  wishes  to  register 
himself  in  the  database  interacts  with  his  local 
agent.  I  h  s  agent  runs  as  a  pnviiegco  program  thai 
has  accc&>  to  the  site  password.  The  agent  engages 
in  a  dialogue  with  the  user  to  authenticate  his 
identity  (for  example,  by  asking  for  a  password) 
and  verifies  that  the  proposed  database  entry  is 
appropnate  to  the  user  (in  particular,  that  the 
"tnaiidox  auurcas'*  ficiu  ptopciijr  Kjcniifies  iik 
user).  Having  satisfied  itself  of  the  validity  of  the 
request,  the  agent  formats  it.  encrypts  it  using  the 
site  password  as  an  encryption  key.  adds  an  unen- 
crypied  header  identifying  the  local  site,  and  for- 
vkards  ii  lo  the  registrar.  The  rexisirar  dccr.pts  the 
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request  and  installs  the  information  in  the  data¬ 
base.  Even  though  the  request  passes  through  un¬ 
secure  channels,  the  potential  for  subversion  is 
limited,  since  the  message  contains  neither  the 
request  nor  the  password  in  plain  text.  Thus  an 
adversary  cannot  modify  the  request  or  use  it  to 
construct  a  bogus  message.  The  encrypted  portion 
of  the  message  also  contains  a  timestamp,  so  that 
an  interloper  cannot  confuse  the  name  server  by 
holding  the  request  and  retransmitting  it  later. 

This  scheme  delegates  authority  for  authenticat¬ 
ing  users  to  the  member  sites.  Each  site  is  held 
responsible  for  all  daubase  entries  that  designate 
that  site  as  sponsoring  organization.  The  agent 
program  (which  is  provided  by  CSNET)  gives  a 
mechanism  for  con’rolling  these  entries.  A  user 
cannot  bypass  this  mechanism  and  send  a  registra¬ 
tion  request  directly  to  the  registrar  because  he 
docs  not  know  the  site  password.  The  registrar  will 
not  accept  requests  for  new  entries  mailed  directly 
from  a  non- member  host,  nor  will  the  the  copy  of 
the  agent  program  resident  on  the  Service  Host 
accept  a  registration  request,  since  the  user  cannot 
be  authenticated  in  either  case.  In  other  words, 
only  a  user  of  a  CSNET  member  host  may  add 
entries  to  the  daubase,  and  he  may  only  do  it 
using  a  local  copy  of  the  CSNET  agent  program. 

Upon  registration,  a  user  may  provide  a  pass¬ 
word  to  be  used  by  him  when  modifying  or  delet¬ 
ing  h)5  directory  database  entry.  This  password 
can  be  used  to  initiate  a  change  request  from  a 
host  other  than  his  sponsoring  machine.  This  fea¬ 
ture  IS  particularly  useful  when  an  individual  moves 
to  a  new  site  and  changes  his  mailbox  address.  The 
registrar  will  inform  the  host  specified  in  the  origi¬ 
nal  database  entry  that  the  entry  has  been  changed. 
This  notification  will  provide  an  additional  check 
to  ensure  that  the  change  is  authorized. 

To  perform  housekeeping  funcuons,  pariicu- 
••;iy  ucictior.  of  defunct  en'rici,  a  site  .may 
authorize  a  special  trusted  user  to  perform  com¬ 
mands  on  behalf  of  other  users  at  that  site. 

This  authentication  mechanisrr  is  not  ''airtight", 
but  should  provide  an  adquate  level  of  protraion 
at  modest  cost.  .More  importantly,  it  delegates 
authority  for  secunty.  so  that  if  breaches  arc  de¬ 
tected.  the  responsible  party  can  be  identified. 

An  interesting  example  of  a  fraud  that  is  not 
prevented  by  this  scheme  might  be  called  "false 
advertising”.  The  owner  of  mailbos 
VESC0(^C0STA-R1C.A  inserts  an  entry  address- 
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1210  W.  Dayton  St.  Madiwn  Wi  ^3706 
phone 

OC!  762-I204 
keys 

sotoman  csnei  contractor  service  host  public  host  computer 
science 
end 

A  user  who  wishes  to  send  mail  to  Solomon 
might  issue  the  command 

whois  Solomon  [csnet  implementor] 

where  the  keyword  “solomon"  is  mandatory,  but 
the  keywords  “csnet"  and  “implementor"  are  op¬ 
tional.  There  may  be  several  entries  containing  the 
keyword  “solomon",  but  the  one  shown  above  is 
the  only  one  containing  either  of  the  words  “csnet" 
or  “implementor".  He  would  receive  the  response: 

In  response  to  (whois  solomon  (csnet  implementor)): 

solomon(^w)K 
Marvin  Solomon 

University  of  Wisconsin  Madison 
Computer  Sciences  Department 
i:!0  W.  Dayton  St.  Madison  WI  33706 
60g-262-l204 

soloman  csnet  contractor  service  host  public  host 
computer  sacnce. 

(The  response  would  be  abbreviated  in  an  interac¬ 
tive  setting.)  He  could  then  send  mail  to  Solomon 
by  addressing  it  to  “solomon(a'uwisc".  Existing 
mail  user  interface  programs  generally  have  a 
nickname  (also  called  “alias")  facility  that  allows 
the  user  to  say  something  like; 

alias  marv  =  vilnmonT^uwisc 

In  avoid  having  to  remember  the  address. 

Solomon  included  "soloman"  as  a  keyword, 
since  he  knew  that  people  frequently  misspell  his 
name  that  way.  The  user  querying  the  database 
can  also  protect  himself  from  misspelling  bv  using 
a  combination  of  wildcards  and  optional  xevwords 
Po.r  example,  he  could  say 

txhoi,  s*  Wisconsin  [soloman  solomon  salemorj 


7.  Phase  2:  Automated  Lookup 

Phase  2  adds  services  to  decrease  the  amount  of 
interaction  requited  between  a  human  user  and  the 
vcniral  database.  In  parncu'iar.  the  mail  uip  and 
ihr  IvKai  agent  are  integrated 
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7./.  Aulomatu  Nickname  Esiablishmenl 

In  Phase  1.  responses  resulting  from  central 
database  lookup  queries  are  always  leturncd  di¬ 
rectly  to  the  user.  In  Phase  2,  facilities  will  be 
add^  to  automate  establishment  of  local  nick¬ 
names. 

Continuing  the  previous  example,  the  interac¬ 
tion  with  the  name  server  and  the  establishment  of 
a  local  nickname  could  be  combined  by  issuing  the 
command 

alias  marv  =  whois(  solomon 

[csnet  implementor]) 

to  the  mail  uip.  which  would  format  a  request  and 
send  it  to  the  registrar.  (No  authentication  is  re¬ 
quited  since  no  change  to  the  nameserver  database 
is  being  requested.)  If  the  query  matches  exactly 
one  entry,  the  nickname  is  installed  in  the  user’s 
private  nickname  table.  If  no  entries  or  more  than 
one  entry  are  returned,  the  response  is  returned  to 
the  user  requesting  more  informitron.  In  the 
PhoneNet  environment,  the  user  receives  notifica¬ 
tion  of  success  or  failure  of  nickname  establish¬ 
ment  in  the  form  of  a  message  mailed  to  him.  A 
facility  will  also  be  provide'l  by  which  a  local 
administrator  can  install  cor^monly  used  aliases  in 
a  table  accessible  to  all  use'i  at  a  site. 

Finally,  the  user  will  be  able  to  combine  query 
of  the  database,  establishment  of  a  nickname,  and 
sending  of  the  first  message  with  a  command  such 
as 

sendto  marv  -  whoislsolcmon 

[csnet  implementor]) 

The  ability  to  combine  these  operations  will  be 
particularly  advantageous  to  PhoneNet  users.  The 
initial  message  will  be  delivered  to  the  PhoneNet 
relav  with  the  keyword  information  and  s  place¬ 
holder  instead  of  .*  mailbox  addrevs  in  the  ’‘To" 
field  The  relay  composes  a  query  to  the  registrar 
and  inteicepts  the  reply.  Assuming  that  a  unique 
match  IS  found,  the  relay  updates  the  message 
header  to  include  the  mailbox  address  (leaving  the 
kev-word  information  in  as  a  comment i  and  de¬ 
liver*.  the  message  as  usual  It  also  forwards  the 
reply  from  the  registrar  back  lo  the  originating 
hint  S'.’  that  the  oroatc  nickname  table  of  the 
sender  can  be  updaicd  The  adsantage  of  this 
scheme  is  that  the  mewage  can  be  delocrcd  after 
onls  one  inseractum  between  the  senJinE  ho^^  and 
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the  relay.  For  example,  if  the  sending  host  is  only 
polled  once  each  day  but  the  destination  host  is 
directly  connected,  this  scheme  provides  next-day 
delivery,  assuming  that  the  list  of  keywords 
uniquely  identifies  one  mailbox.  The  reason  for 
requiring  each  database  entry  to  include  the  user's 
full  name  and  institution  (CSNET  member  organi¬ 
zation).  is  to  give  the  careful  sender  a  reasonable 
chance  of  constructing  a  query  that  will  match 
uniquely  on  the  first  try. 


8.  Phase  3:  Forwarding 

Suppose  an  existing  user  is  assigned  a  mailbox 
on  a  new  host.  Under  some  circumstances,  he  may 
want  that  mailbox  io  be  considered  different  from 
his  previous  mailbox.  For  example,  he  may  have 
changed  jobs.  Under  existing  mail  transport  sys¬ 
tems.  a  message  sent  to  the  old  mailbox  (assuming 
it  was  deleted)  would  be  returned  to  the  sender 
with  an  indication  that  the  mailbox  no  longer 
exists.  A  user  who  is  really  interested  in  sending  to 
him  as  a  person,  rather  than  in  his  official  capacity 
at  his  old  job,  could  query  the  database  to  de¬ 
termine  his  new  iiuutcaa  and  resend  the  mail.  This 
situaiicQ  corresponds  closely  to  the  telephone  sys¬ 
tem  (where  '‘address"  correspondj  to  phone  num¬ 
ber).  However,  under  other  circumstances,  the  user 
would  like  the  change  of  address  to  be  invisible  to 
Kis  correspondents.  For  example,  suppose  he  is 
moved  to  a  different  nost  on  the  basis  uf  an 
administrative  decision  such  as  load-leveling,  or  he 
is  temporarily  visiting  another  site  and  finds  it 
more  convenient  to  have  mail  forwarded  there 
(compare  wnh  the  phone  company's  "call  forward¬ 
ing  "  service)  in  the  latter  case,  we  feel  that  the 
mailbox  is  the  same,  only  us  addrtss  has  changed 
Wc  can  identify  a  "logicar’  mailbox  with  an 
entry  in  the  nameserver  database  The  entry  con¬ 
tains  the  addresi  of  a  ‘'physicai”  inaiil>o\  u-  which 
It  IS  currently  bound.  Each  time  a  message  is  sent 
using  keswords  nr  a  nickname  to  specifs  the  de¬ 
stination.  the  name  server  database  could  be 
searched  to  find  the  correct  current  address  This 
solution  has  several  problems  First,  if  the  Service 
Huai  wtie  queued  each  tsmc  m  message  •i,;s  sent 
usi.ng  keywords,  the  load  would  be  severe  Second, 
a  failure  of  the  Service  Host  or  the  communica- 
noru  path  to  it  would  dclav  sending  of  all  vuih 
messages  \  third  problem  is  the  incrcavcd  v<.'ni 


munications  cost.  Finally,  messages  originating  at 
a  PhoneNet  site  could  be  delayed  an  extra  day  or 
more  waiting  for  a  response  from  the  Service  Host. 

Some  of  these  problems  can  be  mitigated  by 
distributing  he  database.  This  solution  was  chosen 
for  both  the  Grapevine  Registration  Server  (5)  and 
the  Clearinghouse  (11).  However,  a  distributed 
database  poses  certain  difficulties.  If  not  ail  servers 
contain  the  entire  database,  there  is  the  additional 
complexity  of  finding  an  appropriate  server.  On 
the  other  hand,  if  any  of  the  information  is  repli¬ 
cated,  there  is  the  problem  of  maintaining  con¬ 
sistency  over  updates.  Grapevine  and 
Clearinghouse  solve  the  latter  problem  by  allowing 
a  limit^  amount  of  temporary  inconsistency,  as¬ 
suring  only  that  multiple  copics  arc  eventually 
consistent.  We  have  adopted  a  different  approach. 
We  use  a  single  centralized  database,  but  cache 
some  of  the  information  at  multiple  sites,  "The 
cached  information  is  treated  as  a  "hint”;  if  a  part 
of  the  system  discovers  or  suspects  it  is  out  of 
date,  it  consults  the  Service  Host  to  obtain  the 
correct  information. 

S.I.  The  Fonvarding  Mechanism 

To  simplify  various  aspects  of  forwarding,  each 
nameserver  database  entry  will  contain  a  registrar 
non  ID  that  uniquely  and  unambiguously  identi¬ 
fies  the  database  entry.  'This  ID  is  included  in 
database  entries  from  the  start,  but  only  comes 
into  play  in  Phase  3.  (This  idea  wi>  inspired  by  a 
suggestion  of  Denning  and  Comer  [6))  Note  that 
the  registration  ID  identifies  the  database  entn 
and  therefore  the  logical  mailbox.  The  ''mailbox 
address"  field  of  the  entry  is  the  address  of  a 
physical  mailbox  lo  which  ihe  logical  mailbox  is 
currently  bound.  The  mailer  will  be  modified  to 
include  the  registration  ID  in  per-user  nickname 
tables  For  c.xample.  if  a  iser  types 

alias  marv  =  whois(  voli>mon 

(csnci  implementor) ) 

ihc  nickname  table  will  iusre  wnh  the  nickname 
"marv"  not  onlv  the  mailbox  address 
<SOLOMON(ii  I  WISC).  but  also  the  reg's'ratiop 

The  forwarding  mechanism  is  bcsi  described  bv 
an  example  Suppv>vc  Pat  Kane  is  at  siic  A  and  has 
a  .mailbox  witn  addrew  SI  1 1, .A"  He  moves 

tv*  Mie  B  and  iv  refused  the  name  "PAT*  as  h:s 
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mailbox  name  since  there  is  already  a  PAT  there, 
so  he  chooses  the  name  “PKANE”.  The  mailbox 
PAT@SITEA  is  deleted  from  site  A.  Users  who 
bypass  the  CSNET  name  service  entirely  and  send 
to  ‘‘PAT@SITEA”  will  have  their  messages  re¬ 
turned  as  undeliverable.  They  must  learn  from 
channels  outside  of  CSNET  (such  as  word-of- 
mouth)  that  mail  to  Pat  Kane  must  now  be  addre¬ 
ssed  to  “PKANE<gSITEB”.  However,  Pat  Kane 
may  inform  the  registrar  that  he  has  moved. 
(Authentication  of  the  information  uses  a  similar 
mechanism  to  that  described  above  for  registering 
users.)  His  entry  in  the  central  database  is  updated 
to  indicate  his  new  niailbox  address,  so  that  new 
correspondents  looking  for  him  by  keyword  search 
will  find  his  new  address.  Old  correspondents  will 
still  have  mail  returned,  but  now  senden  w)  o  use 
the  name  server  can  have  their  local  mail  syuems 
recover  without  manual  intervention. 

Suppose  sender  “ABE@S1TEC‘  has  esub- 
lished  an  alias  for  Pat  Kane  by  the  command 

alias  pk  =  whois(pat  kane) 

When  the  nickname  was  established,  the  mailer  on 
SITEC  cstabisbed  the  mappings: 

(pk.  ABE)  -(PAT@SITEA.  OOI234-5) 

where  (X)I2345  is  the  registration  ID  of  the  entry 
describing  Pat  Kane.  When  ABE  tries  rending  to 
**pk"  after  Pat  has  moved,  as  message  addressed  to 
■•PAT<gSITEA  (CSNET-ID:  0012345)”  is  sent  to 
SITE.^.  refused,  and  returned  to  sender.  (Current 
mail  systems  treat  the  material  in  parentheses  as  a 
comntent.)  The  sender's  mailer  can  query  the  reg¬ 
istrar  to  find  out  if  there  have  been  any  changes  in 
entry  0012345.  In  this  case,  the  registrar  sends  the 
new  address  "PKANE^SITEB".  and  SITECs 
mailer  updates  iu  tables  to  contain  the  mapping 

(pk.  ABE)  -(PKANE<^S1TEB.  0012345) 

and  re-sends  the  letter  lo  '  FKANE<§S1TEB 
(CSNET-ID.  0012345)"  The  sending  user  is  never 
hi>ihered.  and  all  his  future  mail  to  "pk"  will  be 
sent  diiectly  to  the  correct  address. 

One  additional  complication  arises.  Continuing 
the  previous  example,  suppose  after  Pat  Kane 
leaves  site  A.  Pat  Abie  appears  and  wants  to  be 
known  locally  as  ’’PA'T*.  She  might  well  be  un¬ 
happy  about  being  told  that  she  couldn't  use  the 
name  “P.AT'  because  there  once  was  man  named 
Pat  Kane  who  already  reserved  that  same  name 
On  the  other  hand.  SITE.A  will  have  no  wav  of 
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knowing  whether  mail  addressed  to 
•‘PAT@SI !  EA"  was  intended  for  Pat  Kane  or  Pat 
Able.  Once  again,  senders  who  bypass  CSNET 
software  can  still  send  mail,  but  they  receive  re¬ 
duced  services.  In  this  case,  they  run  the  risk  of  a 
message  going  to  the  wrong  person. 

If  SITEA  is  a  CSNET  member  site,  however,  it 
will  store  the  registration  ID  of  all  its  local  users 
who  are  registered.  If  an  incoming  message  con¬ 
tains  a  registration  ID  that  does  not  match  the 
registration  ID  of  the  addressee,  the  message  will 
be  rejected.  When  Pat  Kane  changes  his  address  to 
”PKANE<gSrrEB‘’.  the  registrar  informs  SITEA 
the  the  user  id  ”PAT:(X)  12345"  is  no  longer  valid. 

Phase  3  requires  modifications  both  ic  the  mail 
user-interface  program  and  to  the  programs  that 
send  and  receive  mail  from  outside  the  host.  The 
uip  riust  store  the  registration  ID  with  cached 
addressee  from  the  name  server  and  include  it  in 
messages.  The  program  that  receives  mail  from  the 
network  will  be  modified  to  do  additional  check¬ 
ing  on  the  validity  of  messages  that  contain  a 
registration  ID.  rejecting  them  if  the  address  and 
registration  ID  do  not  match  according  to  tables 
at  the  receiving  host.  The  program  that  delivers 
mail  to  the  network  will  be  ttiudiiied  to  do  extra 
checking  for  mesuges  fleeted  by  the  destination, 
going  to  the  central  database  to  verify  addresses  of 
rejected  messages. 

These  changes  might  be  viewed  as  delaying  the 
binding  of  name  to  address  (7).  In  the  existing 
system,  the  ”user(^host"  string  is  an  address  sup¬ 
plied  by  the  mail-preparation  software  when  the 
message  is  created.  With  the  phasc-3  modifica¬ 
tions.  the  uip  denotes  the  destination  of  the  mes¬ 
sage  by  Its  rc^s'.ration  ID  (the  name  of  the  logical 
mailbox)  and  includes  a  suggested  address  where  it 
mighi  be  found.  The  binding  of  name  to  address 
occurs  in  two  stages,  first  trying  the  suggesied 
address  and  then  accesvina  ihe  central  database  if 
tiic  iuggesiion  proves  incorrect. 

8.2.  Opitmizationt 

The  update  message  from  the  registrar  to  SITEA 
could  include  the  forwarding  address,  and  S1TE,A 
could  cache  y  *0;  icccr>t«> 

moved  mailboxes  When  ihe  letter  addressed  to 
••PAT<g  SITEA  (CSNET-ID  0012345)"  arnvei  at 
S!TK.\.  SirE.A  could  then  send  it  dircctlv  10 
PkASE<a  SITES  rather  than  reiurninf  it  to  the 
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sender.  It  should  still  inlorm  the  sender  of  the 
change,  and  the  sender  may  well  wish  to  check  the 
new  address  with  the  registrar  rather  than  trusting 
SITEA,  ^  It  the  delay  in  delivering  the  letter  would 
still  be  reduced  from  five  message-transition  times 
(sender  to  SITEA:  SITEA  to  sender:  sender  to 
Service  Host:  Service  Host  to  sender:  sender  to 
SITEB).  to  two  (sender  to  SITEA:  SITEA  to 
SITEB).  The  possibility  of  this  sort  of  forwarding 
ffiies  difficult  problems  in  billing,  however  (e.g.. 
who  pays  for  the  forwarding  hop  and  how  is  he 
biUed),  which  are  beyond  the  scope  of  this  paper. 

Another  opumiiaiion  is  based  on  the  observa¬ 
tion  that  it  is  comnK»  for  several  users  at  one  site 
to  correspond  with  the  same  person.  If  they  all 
have  obsolete  nicknames  for  him.  the  overhead  of 
a  misdirected  message  can  b?  moved  from  the  first 
lime  each  of  them  sends  to  him  to  the  first  time 
any  of  them  sends  to  him.  Instead  of  storing  the 
entry  “pk**:  PAT(8S1TEA  (CSNET-ID  0012345)” 
in  the  nickname  uble  for  a  user,  we  will  store  an 
entry  Uke  “pk:  0012345”  in  the  per-user  table  and 
mainuin  a  per-hosi  table  with  the  entry 
•X)0 1 2345 :  PaU^SITEA”. 

rinally.  more  of  the  iafonmilion  may  be  cached 
in  various  hosts.  In  particular,  each  PhoneNet 
relay  will  keep  a  copy  of  the  complete  mapping 
from  regisiraiion  ID*s  to  mailbox  addresses.  When 
a  mcss*f«  is  sent  from  a  Ph‘'r»eNet  site  to  an 
obsolete  address,  the  relay  can  query  the  central 
database  and  retransmit  the  message  to  the  proper 
destination  wiUioui  the  cost  and  delay  of  com¬ 
munication  with  the  sending  site.  From  the  point 
of  view  of  a  PhoneNet  site,  the  registration  ID  acts 
as  an  address,  and  the  translation  to  the  correct 
USER<|HOST  mailbox  address  may  be  con¬ 
sidered  part  of  the  translation  from  address  to 
route. 

f .  Mailing  Lists 

Al!  the  mechanism*  desenbed  thus  far  are  tech¬ 
niques  for  discovering  the  address  of  one  mailbox 
There  is  nothing  to  orevent  them  from  being  used 
repeatedly  and  in  combination  to  develop  multiple 
sddmsff  a  single  such  as 

sendto 

marv. 

larry  =  » hoist  lai* rente  landwcher 

Wisconsin). 

donn(a  u»iw 


which  names  the  three  authors  of  this  paper  by  a 
nickname,  a  keyword  search,  and  a  mailbox  ad¬ 
dress.  respectively. 

A  related  facility  is  the  mailing  list  which  is  a 
name  for  a  list  of  mailboxes  that  are  often  used 
together.  Existing  user  interface  programs  often 
provide  a  mailing  list  function  using  the  nickname 
facility  to  do  a  macro  expansion  of  a  mailing  list 
name.  In  Phase  3.  the  CSNET  name  server  will 
allow  users  to  register  mailing  lists  in  the  central 
directory  database.  A  mailing  list  entry  is  similar 
to  other  entries  in  that  it  contains  a  list  of  keywords 
and  identification  of  a  user  responsible  for  the 
entry.  But  it  also  contains  a  list  of  items,  which 
can  be  mailbox  addresses.  CSNET  ID  s.  and  names 
of  other  mailing  lists.  A  request  to  add  a  mailing 
list  to  i.he  directory  contains  the  keywords  describ¬ 
ing  the  list,  as  well  as  descriptions  of  the  members, 
specified  by  any  convenient  means  (i.e..  keywords, 
nickne me.  or  mailbox  address).  On  receiving  such 
a  request  (which  must  pass  the  usual  access  checks), 
the  registrar  stores  the  list,  after  replacing  those 
members  specified  by  keywords  or  nicknames  by 
the  corresponding  CSNET  ID’s.  (The  Usi  is  al¬ 
lowed  to  contain  mailbox  addresses  to  accommod¬ 
ate  unregistered  members.)  If  any  member  specifi¬ 
cation  fails  to  resolve  to  a  unique  address,  the 
request  will  be  returned  to  the  senoer  ior  correc¬ 
tion. 

When  a  mailing  list  is  installed,  the  registrar 
will  send  a  message  containing  the  names  of  all  the 
members  to  each  member.  (This  notification  may 
be  suppressed.)  Similarly,  a  change  in  the  mailing 
list  can  generate  a  notificaiK'sn  to  all  paraes 
involved. 


10.  Comparison  to  Other  Work 

Several  reports  have  been  published  on  "name 
servers”  for  computer  netuiorks  jS-lOj  In  ihc 
ARP.A  internet  community,  the  term  ’name  server 
IS  often  used  lo  mean  a  service  for  translating  host 
names  (such  as  "CSNET-SH'  )  to  ):  btt  internci 
addresses  (such  as  1200200136)  useu  by  the  trans¬ 
port  level  to  address  a  host  The  Senice  Host  will 
also  provide  a  name  service  in  ihis  sense,  bui 
discussion  of  ihat  service  is  ouiside  the  scope  of 
this  f  aper 

Tvko  particulariv  inieresiin|  reUied  name  server 
designs  are  ihe  Grapevine  regisira  >n  service  15 1 
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and  ihc  Clearinghouse  [llj  both  at  Xerox  PARC. 
Both  services  provide  for  naming,  autheniicating. 
and  locating  people,  machines,  and  services  in  a 
multinetwork  environment.  The  Grapevine  reg¬ 
istration  service  provides  for  the  translation  of 
two-part  names  to  other  names,  lists  of  names,  or 
internet  addresses.  The  set  of  names  with  the  same 
first  component  is  called  a  registry.  Tne  registra¬ 
tion  service  is  provided  by  several  dedicated  reg- 
istraticn  servers,  each  of  which  holds  all  informa¬ 
tion  about  one  or  more  registries,  and  each  registry 
may  be  stored  at  one  or  more  servers. 

The  Clearinghouse  extends  these  ideas  by  pro¬ 
viding  a  more  complex  organization  of  registries 
and  servers  and  by  extending  the  class  of  values  to 
which  nancs  arc  bound.  Names  have  the  ferma! 
“Individual@Domain@Organi2ation“,  where  the 
intention  seems  to  be  that  “Organization**  is  a 
corporate  entity  (such  as  “Xerox*’),  “Domain**  is 
an  administrative  division  of  the  company  (such  as 
"SDD**),  and  “Individual'*  may  be  a  person  or  a 
component  of  the  computer  system,  such  as  a 
server.  Names  arc  guaranteed  to  be  globally  unam¬ 
biguous  (that  is  no  two  objects  have  the  same 
name)  by  requiring  the  domain  name  to  be  unique 
in  2  dotnain.  !n  the  exw*  of  human  individuals,  the 
name  is  the  person*s  full  name,  possibly  with  a 
“birthmark**  affued  to  assure  uniqueness.  Names 
are  proposed  by  a  human  administrator  and  veri¬ 
fied  for  uniqueness  by  We  system  itself.  Each 
name  is  bound  to  a  property-list,  with  property 
names  chosen  from  a  fixed  set  of  possibilities  and 
values  which  may  be  individuals  or  lists.  The 
database  contains  information  on  its  own  struc¬ 
ture.  for  example,  there  is  a  registry 
"SDD<g'XefOx<gCleannghouse‘'  that  lists  servers 
for  names  in  domain  "SDD”  of  organization 
“Xerox".  An  interesting  aigoriihm  uses  i.*u>  infor¬ 
mation  ic  find  a  server  with  the  binding  of  a  given 
name. 

Both  sf  these  svstemi  ire  desssned  u>  npefxi*  in 
an  iniemeiwork  enstronment  with  associated 
databases  and  services  disinbuted  among  different 
machines  on  different  networks.  Therefore,  many 
of  the  complications  that  concern  the  authors  of 
these  papers,  such  as  how  to  find  a  name  server 
and  Knw  in  maintain  consistency  between  repit- 
ciied  copies  of  a  registry  do  not  anse  m  cur 
toniesi.  m  wkH  there  is  a  unique  name  server  at  a 
address  On  the  other  hand,  these 

stems  are  desii^ned  for  ensirimments  m  whish 


!7I 

message-passing  is  cheap  and  quick,  and  in  which 
broadcast  is  a  viable  means  for  locating  services. 
Some  of  their  techniques  do  not  apply  in  an 
environment  in  which  a  single  message  “hop**  can 
take  more  than  a  day. 

Another  difference  is  in  how  the  systems  are  to 
be  used.  The  designers  of  Grapevine  and  the 
Clearinghouse  have  chosen  to  limit  their  function¬ 
ality  to  a  simple  name  lookup,  removing  more 
complex  database  query  functions  to  client  soft¬ 
ware  that  uses  the  services  of  the  registration  server. 
A  lookup  request  to  Clearinghouse,  for  example, 
must  fully  specify  a  three-part  name,  possibly  with 
’’wildcard**  characters,  for  c;xample 
“•(gSDD(gXerox’*.  There  is  no  support  for  con- 
t^fii.pddrfc^'d  queries.  In  our  system,  the  primary 
goal  is  to  facilitate  lookup  of  mailbox  addresses 
based  on  incomplete  information.  Hence,  it  is  not 
necessary  to  know  any  particular  piece  of  informa¬ 
tion  such  as  the  user's  complete  na  *  to  locate  his 
entry. 

II.  Summary 

We  have  presented  a  detailed  specification  of  a 
name  server  facility  for  CSNET  and  have  sketched 
out  the  algorithms  for  implementing  it.  The  facility 
is  implemented  by  a  postmaster  general  program 
ninning  on  the  Service  Host  and  local  agent  pro¬ 
grams  runmng  on  local  hosts.  The  facility  will  be 
implemented  as  a  series  of  enhancements  to  exist¬ 
ing  services,  each  adding  more  convenience  for 
users.  It  assumes  a  mail  transport  system  that  can 
deliver  a  message  when  presented  with  a  list  of 
destination  addresses.  It  also  allows  for  interactive 
daiaba'C  access  in  cases  in  which  the  user  or  the 
u  er’s  host  is  capable  of  direct  avr.nectior  to  the 
Service  Host. 

We  have  deliberately  avoided  discussing  issues 
involving  the  mail  transport  system,  such  as  rout- 
jfij.  mail  rrUys.  multicast  delivery,  or  repJy-uv- 
sender.  except  as  ihe^  are  directls  related  to  the 
name  server,  but  we  do  not  beiiese  that  the  name 
server  faciUiy  creates  any  new  problems  in  these 
areas  since  address  specifications  ultinuteh  re- 
solve  to  addresses  in  the  style  already  m  use  We 
have  also  not  tied  the  name  server  spec/ication  to 
a  particular  mail  interface  program. 

The  central  database  is  structured  as  a  sequence 
of  fiscd  length  rrcofds  one  per  ens.'v.  wiih  4 
separate  overflvm  area  b'f  long  entries  An  tn- 
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verted  index  also  consists  of  a  sequence  of  records, 
one  for  each  word  appearing  in  the  database.  Each 
record  contains  a  list  of  pointers  to  entries  con* 
taining  the  word.  A  hash  ubie  speeds  access  to  the 
index.  A  database  access  program  does  all  lookups 
and  modiftcalions  of  the  database.  It  can  be  in¬ 
voked  by  an  agent  program  on  the  Service  Host, 
an  agent  connected  to  the  access  program  by  a 
virtual-termiRr^J  protocol,  or  by  a  mail  opener  pro¬ 
gram  that  aocepu  and  validates  mail  requests.  A 
monitor  process  controls  concurrent  access  to  the 
daubase  by  multiple  copies  of  the  access  program. 

The  techniques  for  implementing  the  algorithms 
described  he»^  are  well  understood,  and  tools  (such 
as  a  flexible  filesystem  and  encryption  programs) 
are  already  in  place  in  the  operating  system  for  the 
Service  Host  Therefore,  we  feel  that  the  name 
server  can  be  implemented  quickly  and  begin  to 
provide  services  to  users  soon.  At  the  time  of  this 
writing  (February,  1982)  Phase  1  is  implemented 
and  undergoing  testing.  The  remaining  phases  are 
expected  to  be  completed  in  the  next  year. 
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INTRODUCTION 


This  nemo  defines  the  procedure  to  acccuss  an  Internet  Name  Server.  Such 
a  server  provides  the  actual  addresses  of  hosts  in  the  internet  vhen 
supplied  with  a  host  name.  An  Internet  Name  Server  is  a  dynamic 
nane- to -number  translation  service. 

This  server  utilizes  the  User  Datagram  Protocol  (UDP)  [2] ,  which  in  turn 
calls  on  the  Internet  Protocol  (IP)  [3] . 

NAME  SYNTAX 


It  is  strongly  raccanmended  that  the  use  of  host  names  in  programs  be 
consistent  for  both  irput  and  output  across  all  hosts.  To  promote  such 
consistency  of  the  internet  level,  the  following  syntax  is  specified: 

The  SYNTAX  of  names  as  n'esented  to  the  user  and  as  entered  by  tha  'jser 
is: 

!  NET  !  REST 
where: 

NET  is  a  network  name  or  number  as  defined  in  "Assigned  Numbers"  [1] 
and 

REST  is  a  host  name  within  that  network  expressed  as  a  character 
string  or  as  a  number.  When  a  number  is  uscxl,  it  is  expressed  in 
decimal  and  is  prefixed  with  a  sharp  sign  (e.g.,  #1234) . 

Note  that  this  syntax  has  minimal  impact  on  the  allowable  character 
strings  for  host  names  within  a  network.  The  only  restriction  is  that 
a  REST  string  cannot  begin  with  an  exclamation  point  (!)  . 

The  !NET!  may  be  omitted  when  specifying  a  host  in  the  local  network. 
That  is  "!"  indicates  the  network  portion  of  a  name  string. 
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BASIC  NAME  SERVER 


To  aid  in  the  translation  of  names  to  Internet  addresses,  several  name 
server  processes  will  be  provided.  The  name  server  process  will  accept 
a  name  In  the  above  form  and  will  return  a  name,  address  pair. 

The  name  server  processes  will  have  well-known  addresses;  addresses  that 
are  constant  over  long  periods  of  time  and  published  In  documents  such 
as  "Assigned  Numbers"  [1] . 


A  request  sent  to  a  name  server  Is  sent  as  a  user  datagram  [2]  with  the 
following  content: 


+ - + - - + - - 4.. 

I  I  I 

I  NAME  I  LENGTH  |  NAME  STRING 

I  I  I 

4 - 4 - 4 - 4 4 - 4. 


4— \\ 

4— \\ 


where: 


NAME  Is  a  one  octet  code  Indicating  that  the  following  Is  a  name, 

LENGTH  Is  a  one  octet  count  of  the  number  of  octets  in  the  name 
string,  and 

NAME  STRING  Is  an  ASCII  character  string  of  the  form  !  NET  t  REST. 

A  reply  to  a  successful  translation  Is  sent  as  a  user  datagram  with  the 
following  content: 

+ . . ♦ . . — . + - +"--\\ — + 


I  NAME  I  LENGTH  |  NAME  STRING  j 

III  I 

. + . + . + . + . + . 4---\\---  + 

III  I 

(  ^DDRESS|  LENGTH  |  INTERNET  ADDRESS  | 

III  I 

4 - 4 - 4 - 4 - 4 - 4 - 4 
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Internet  Name  Server 


vhere: 

ADDEIESS  is  a  one  octet  code  indicating  that  the  following  is  an 
internet  address, 

LENGTH  is  a  one  octet  count  (=4)  of  the  length  of  the  internet 
address,  and 

INTEBNET  ADDEIESS  is  the  internet  address. 

Actually  a  particular  name  mig^t  map  to  several  internet  addresses,  in 
this  case  the  response  would  include  a  list  of  internet  addresses. 

When  a  name  is  not  found,  an  error  is  reported  via  a  user  datagram  as 
follows: 


NAME 

-+ - +- 

1  1 

1  LENGIH  1 

1  1 

NAME  STRING 

_ M _ \.\ _ 

1  1 

ERROR  i 

ERROR 

i  LENGTH  1 

1  1 
- 

CODE  i 

1 

ERROR  STRING 

- 

where: 

CCX)E  specifies  the  error. 

ERROR  STRING  ejqplains  the  error. 
Error  Codes 

The  following  error  codes  are  defined: 
CODE  MEANING 


0  Undetermined  or  undefined  error 

1  Name  not  found 

2  Ivproper  name  syntax 

Communication  with  a  Name  Server  Process 

Communication  with  a  name  server  process  is  via  user  datagrams, 
datagrams  do  not  guarantee  reliable  communication.  Thus, 

requests  or  replies  may  be  lost. 
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The  name  server  process  is  a  transaction  oriented  process; 
furthermore,  the  nature  of  the  transactions  allows  them  to  be 
processed  In  any  order  and  even  to  be  duplicated.  This  allows  the  use 
of  a  very  slsple  communication  protocol. 

If  a  request  Is  made  to  the  name  server  process  and  no  response  Is 
received  within  a  reasonable  time,  then  the  requester  should  make  the 
request  again.  This  recovers  from  communication  errors  which  cause 
the  loss  of  either  the  request  or  the  reply. 

In  order  to  use  this  slsple  strategy,  care  must  be  taken  to  allow 
replies  to  be  properly  matched  with  requests.  The  name  server  process 
does  this  by  Including  In  each  reply  a  copy  of  the  entire  request. 

The  user  datagram  protocol  does  provide  a  checksum  for  the  detection 
of  errors. 

format 

The  requests  and  replies  to  and  from  a  name  server  process  are  encoded 
as  "Items".  An  Item  consists  of  an  Item-code  an  Item- length  and  the 
Item-data.  The  Item- length  Includes  In  Its  count  the  Item-count  and 
the  Item- length  octets. 

Item  :=  Item-Code  Item-Length  Item-Data 


1  Item 

1  Item  1 

1  Code 

1  Length  j 

A  reqijest  Is  typically  one  Item,  and  a  reply  Is  typically  two  Items. 


I  ItemCodel Item  Len{ . . .  Item  Data  . . . | 

y - + - + - + - + 

I  .  Item  Data  cont  .  | 

y - + - + - + - + 

I  Item  Data  cont.  | ItemCode| Item  Len| 

K - + - + - + - + 

I  .  Item  Data .  | 

I- - + - + - + - + 
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Item  Code  Value  Assignments: 
NAME  =  1 
ADDEIESS  =  2 
ERROR  =  3 
Example 

a  typical  request: 


and  the  reply: 


1 

1 

1 

12 

1 

I 

1 

A 

1 

1 

R 

1 

P 

I 

A 

1 

! 

1 

Hr*  ■ 

1 

I 

1 

S 

1 

I 

1 

B 

1 

1 

1 

1 

12 

1 

1 

1 

A 

1 

T  *  • 

1 

R 

1 

P 

1 

A 

•  *▼*  • 

1 

1 

*  *  T 

1 

1 

I 

1 

S 

1 

I 

i 

B 

1 

+  *  " 

1 

2 

1 

6 

1 

10 

1 

3 

*  *  T 

1 

1 

0 

1 

52 

1 

•  *T  *  ' 

*  *T 
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EXTENDED  NAME  SERVER 

Several  extensions  have  been  proposed  [4] ,  the  following  two  are 
adopted:  partially  specified  names,  and  a  service  field. 

In  the  first  extension  partially  specified  names  are  allowed  and  are 
indicated  by  the  use  of  "wild  card"  fields  or  characters. 

Wild  Card  Field  Meaning 


^  All 

•  Local  (Same  as  that  of  the  requestor) 

Wild  Card  Character  Meaning 


* 

Any  substring 

Examples 

: 

!  - 1  * 

all  hosts  on  the  net  of  the  requestor. 

!*!SRI 

*■  all  hosts  with  names  whose  first  three  characters 
are  SRI  on  all  nets 

In  general,  there  are  three  cases  for  each  of  the  net  and  host 
Using  the  symbols  N  for  named  network  and  H  for  named  host  the 
are: 

fields. 
9  cases 

! " !  ^ 

local  not,  local  host 

1  - !  * 

local  net,  all  hosts 

!-!H 

local  net,  named  host 

!  *  I - 

all  nets,  local  host 

1  *  { * 

all  nets,  all  hosts 

!*!H 

all  nets,  named  host 

!N!- 

named  net,  local  host 

!N!* 

named  net,  all  hosts 

!N!H 

named  net,  named  host 
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When  such  a  request  Is  processed  and  the  result  Is  more  than  one 
name/address  pair,  the  response  Is  all  the  pairs. 

Examples: 

1) 

request: 

!ARPA!ISI* 

response: 


!ARPA!ISIA 

10 

1 

0 

22 

!ARPA!ISIB 

10 

3 

0 

52 

!ARPA!ISIC 

10 

2 

0 

22 

!ARPA!ISID 

10 

3 

0 

22 

!ARPA!ISIE 

10 

1 

0 

52 

2) 

request: 

!-!SRI-R2D2 

reiqponse: 

!ARPA!SRI'R2D2  10  3  0  51 
!SF-PR-1!SRI-R2D2  2  0  0  11 
3) 

request: 

!*!ISIA 

response: 

•ARPAilSIA  10  1  0  22 

The  second  extension  Is  that  a  third  field  may  be  appetided  to  the  name. 
This  Is  the  SERVICE  field. 
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!  NET  !  HOST  !  SERVICE 

To  reply  to  a  request  of  this  form  the  name  server  must  provide  the 
internet  address  (net  and  host) ,  the  protocol  nuniber,  and  the  port 
nuiDber. 

^ - ^ - ^ - + - ^ - - ^ + 

III  I 

I  NAME  I  LENGTH  |  NAME  STRING  | 

III  ! 

+ - ^ - + - + - . ^ - ^ - \\ - + 

III  I 

I  ADDRESS)  LENGTH  |  INTERNET  ADDRESS  | 

III  I 

•f - - ^ - ^ - ^ - ^ 

I  I  I  I 

jPRCTOCOLI  PC3RT  | 

I  I  I  I 

+ - + - ^ - + 

Exanples: 

1) 

request: 

!ARPA!ISIA!TELNET 

re^xanse: 

•ARPAIISIA'.TELNET  10  1  0  22  6  0  23 

2) 

request: 

!ARPA!*!NAME-SERVER 

response: 

lARPA!  SRI -KL!  NAME-SERVER  10  1  0  2  17  42 
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PREFACE 


This  is  the  second  edition  of  this  specification  and  should  be  treated 
as  a  request  for  connnents^  advice,  and  suggestions.  A  great  deal  of 
prior  work  has  been  done  on  conputer  aided  message  systfsms  and  some  of 
this  is  listed  in  the  reference  section.  This  specification  was  shaped 
by  many  discussions  with  members  of  the  ARPA  research  community,  and 
others  interested  in  the  development  of  conputer  aided  message  systems. 
This  document  was  prepared  as  part  of  the  ARPA  sponsored  Internetwork 
Concepts  Research  Project  at  ISI,  with  the  assistance  of  Greg  Finn, 
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1.  INTRODUCTI.IN 

Hiis  document  describes  an  Internetwork  message  system.  The  system  is 
designed  to  transmit  messages  between  message  processing  modules 
according  to  formats  and  procedures  specified  in  this  document.  'Ihe 
message  processing  modi  Jes  are  processes  in  host  cooputers.  Message 
processing  modules  are  located  in  different  networks  and  togf^ther 
constitute  an  internetwork  message  delivery  system. 

This  document  is  intended  to  provide  all  the  information  necessary  to 
Implement  a  compatible  cooperating  module  of  this  internetwork  message 
delivery  system. 

1.1.  Motivation 

As  computer  supported  message  processing  activities  grow  on  Individual 
host  coEputers  and  in  networks  of  computers,  there  is  a  natural  desire 
to  provide  for  the  Interconnection  and  interworking  of  such  systems. 
This  specification  describes  the  formats  and  procedures  of  a  general 
purpose  internetwork  message  system,  which  can  be  used  as  a  standard 
for  the  interconnection  of  individual  message  systems,  or  as  a  message 
delivery  system  in  its  own  ri^^t. 

This  system  also  provides  for  the  communication  of  data  items  beyond 
the  scope  of  contemporary  message  systems.  Messages  can  include  data 
objects  \rtiich  could  represent  drawings,  or  facsimile  images,  or 
digitized  speech.  One  can  imagine  message  stations  equipped  with 
speakers  and  microphones  (or  telephone  hand  sets)  where  the  body  of  a 
message  or  a  portion  of  it  is  recorded  digitized  speech.  The  output 
terminal  could  include  a  graphics  display,  and  the  message  might 
present  a  drawing  on  the  display,  and  verbally  (via  the  speaker) 
describe  certain  features  of  the  drawing.  This  specification  provides 
for  the  composition  of  complex  data  objects  and  their  encoding  in 
machine  independent  basic  data  elements. 

1.2.  Scop)e 

The  Internet  Message  Protocol  is  intended  to  be  used  for  the 
transmission  of  messages  between  networks.  It  may  also  be  used  for 
the  local  message  system  of  a  network  or  host.  This  specification  was 
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developed  in  the  context  of  the  ARPA  work  on  the  interconnection  of 
networks,  but  it  is  thouc^t  that  it  has  a  more  general  scope. 

The  focus  here  is  on  the  internal  mechanisms  to  transmit  messages, 
rather  than  the  external  interface  to  users.  It  is  assumed  that  a 
number  of  user  interface  programs  will  exist.  These  will  be  both  new 
programs  designed  to  work  with  this  system  and  old  programs  designed 
to  work  vfith  earlier  systems. 

1.3.  The  Internetwork  Environment 

The  internetwork  message  environment  consists  of  processes  which  run 
in  hosts  which  are  connected  to  networks  which  are  interconnected  by 
gateways.  Each  network  consists  of  many  different  hosts.  The 
networks  are  tied  together  through  gateways.  The  gateways  are 
essentially  hosts  on  two  (or  more)  networks  and  are  not  assumed  to 
have  much  storage  capacity  or  to  -’know''  which  hosts  are  on  the 
networks  to  which  they  are  attached  [1,2]  . 

1.4.  Model  oi  Operation 

This  protocol  is  inplemented  in  a  process  called  a  Message  Processing 
Module  or  MPM.  The  MPMs  exchange  messages  by  establishing  full  duplex 
communication  and  sending  the  messages  jjr>  a  fixed  format  described  in 
this  document.  The  MPM  may  also  communicate  other  information  by 
means  of  commands  described  here. 

A  message  is  formed  by  a  user  interacting  with  a  User  Interface 
Program  or  UIP.  The  user  may  utilize  several  commands  to  create 
various  fields  of  the  message  and  may  invoke  an  editor  program  to 
correct  or  format  some  or  all  of  the  message.  Once  the  user  is 
satisfied  with  the  message  it  is  submitted  for  transmission  by  placing 
it  in  a  data  structure  read  by  the  MPM. 

The  MPM  discovers  the  unprocessed  input  data  (either  by  a  specific 
request  or  by  a  general  background  search) ,  examines  it,  and,  using 
routing  tables  (or  some  other  method)  ,  determines  which  outgoing  link 
to  use.  The  destination  may  be  another  user  on  the  same  host,  one  on 
another  host  on  a  network  in  common  with  the  same  host,  or  a  user  in 
another  network. 

In  the  first  case,  another  user  on  this  host,  the  MPM  places  the 
message  in  a  data  structure  read  by  the  destination  user,  where  that 
user's  UIP  will  look  for  incoming  messages. 

In  the  second  case,  the  user  on  another  host  in  this  network,  the  MPM 
transmits  the  message  to  the  MPM  on  that  host.  That  MPM  then  repeats 
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the  routing  decision,  and  discovering  the  destination  is  local  to  it, 
places  the  message  in  the  data  structure  shared  with  the  destination 


In  the  third  case,  the  user  on  a  host  in  another  network,  the  MPM 
transmits  the  messages  to  an  MPM  in  that  network  if  it  knows  how  to 
establish  a  connection  directly  to  it;  otherwise,  the  MPM  transmits 
the  message  to  an  MPM  that  is  "closer"  to  the  destination.  An  MPM 
mig^it  not  know  of  direct  connections  to  MPMs  in  all  other  networks, 
but  it  must  be  able  to  select  a  next  ME>M  to  handle  the  message  for 
each  possible  destination  network. 

An  ME^  mig^t  know  a  way  to  establish  direct  connections  to  each  of  a 
few  ME^  in  other  nearby  networks,  and  send  all  other  messages  to  a 
particular  big  brother  MPM  that  has  a  wider  knowledge  of  the  internet 
environment . 

An  individual  network's  message  system  may  be  quite  different  from  the 
internet  message  system.  In  this  case,  intranet  messages  will  be 
delivered  using  the  network's  own  message  system.  If  a  message  is 
addressed  outside  the  network,  it  is  given  to  an  MPM  which  then  sends 
it  throu^  the  appropriate  gateways  to  (or  towards)  the  MPM  in  the 
destination  network.  Eventually,  the  message  gets  to  an  MPM  on  the 
network  of  the  recipient  of  the  message.  The  message  is  then  sent  via 
the  local  message  system  to  that  host. 

When  local  message  protocols  are  used,  special  conversion  programs  are 
required  to  transform  local  messages  to  internet  format  when  they  are 
going  out,  and  to  transform  internet  messages  to  local  format  when 
they  come  into  the  local  environment.  Such  transformations 
potentially  lead  to  Information  loss.  The  internet  message  format 
attenpts  to  provide  features  to  capture  all  the  information  any  local 
message  system  migfit  use.  However,  a  particular  local  message  system 
is  unlikely  to  have  features  equivalent  to  all  the  possible  features 
of  the  internet  message  system.  Thus,  in  some  cases  the 
transformation  of  an  internet  message  to  a  local  message  discards  some 
of  the  information.  For  exanple,  if  an  internet  message  carrying 
mixed  text  and  speech  data  in  the  body  is  to  be  delivered  in  a  local 
system  which  only  carries  text,  the  speech  data  may  be  replaced  by  the 
text  string  "There  was  some  speecn  here” .  Such  discarding  of 
information  is  to  be  avoided  when  at  all  possible,  and  to  be  deferred 
as  long  as  possible;  still,  the  possibility  remains  that  in  some  cases 
it  is  the  only  reasonable  thing  to  do. 
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1.5.  Interfaces 

The  MPM  calls  on  a  reliable  communication  procedure  to  communicate 
with  other  MPMs.  This  is  a  Transport  Level  protocol  such  as  the 
Transmission  Control  Protocol  (TCP)  [3]  .  The  interface  to  such  a 
procedure  conventionally  provides  calls  to  open  and  close  connections, 
send  and  receive  data  on  a  connection,  and  some  means  to  signal  and  be 
notified  of  special  conditions  (i.e.,  interrupts) . 

The  MPM  receives  input  and  produces  output  throug^i  data  structures 
that  are  produced  and  consumed  respectively  by  user  interface  (or 
other)  p  "ograms . 
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2.  FUNCTIONAL  DESCRIPTION 

Tliis  section  gives  an  overview  of  the  Internet  Message  System  and  its 
environment . 

2.1.  Terminology 

The  messages  are  routed  by  a  process  called  the  Message  Processing 
Module  or  MPM.  Messages  are  created  and  consurced  by  User  Interface 
Programs  (UIPs)  in  conjunction  with  users. 

The  basic  unit  transferred  between  MPMs  is  called  a  message.  A 
message  is  made  tp  of  a  transaction  identifier  (which  uniquely 
identifies  the  message) ,  a  command  (which  contains  the  necessary 
information  for  delivery),  and  document.  The  document  may  have  a 
header  and  a  body. 

For  a  personal  letter  the  document  body  corre^onds  to  the  contents  of 
the  letter;  the  document  header  corresponds  to  the  date  line, 
greeting,  and  signature. 

For  an  inter-office  memo  the  document  body  corre^onds  to  the  text; 
the  document  header  corresponds  to  the  header  of  the  memo. 

The  commands  correspond  to  the  information  used  by  the  Post  Office  or 
the  mail  room  to  route  the  letter  or  memo.  Some  of  the  information  in 
the  command  is  supplied  by  the  UIP. 

2.2.  Assumptions 

The  following  assunptions  are  made  about  the  internetwork  environment: 

In  general,  it  is  not  known  what  format  intranet  addresses  will 
assume.  Since  no  standard  addressing  scheme  would  suit  all  networks, 
it  is  safe  to  assume  there  will  be  several  and  that  they  will  change 
with  time.  Thus,  frequent  software  modification  throughout  all 
internet  MPMs  would  be  required  if  such  MPMs  were  to  know  about  the 
formats  on  many  networks.  Therefore,  each  MPM  which  handles  internet 
messages  is  required  to  know  only  the  minimum  necessary  to  deliver 
them. 

Each  MPM  is  required  to  know  conpletely  only  the  addressing  format  of 
its  own  network  (s)  .  In  addition,  the  MPM  must  be  able  to  select  an 
output  link  for  each  message  addressed  to  another  network  or  host. 

This  does  not  preclude  more  intelligent  behavior  on  the  part  of  a 
given  MPM,  but  at  least  this  minimum  is  necessary.  Each  network  has  a 
unique  name  and  numeric  address.  Such  names  and  addresses  are 
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registered  with  a  naming  authority  and  may  be  listed  in  documents  such 
as  Assigned  Numbers  [4]  . 

Each  MPM  will  have  a  unique  internet  address.  This  feature  will 
enable  every  MPM  to  place  a  unique  "handling-stamp"  on  a  message  which 
passes  through  the  MPM  enroute  to  delivery. 

2.3.  Gei.«5i*al  Specification 

There  are  several  aspects  to  a  distributed  service  to  be  specified. 
First,  there  is  the  service  to  be  provided;  that  is,  the 
characteristics  of  the  service  as  seen  by  its  users.  Second,  there  is 
the  service  it  uses;  that  is,  the  characteristics  it  assumes  to  be 
provided  by  some  lower  level  service.  And  third,  there  is  the 
protocol  used  between  the  modules  of  the  distributed  service. 


User 

\ 

UIP 

\ 


User 

/ 

UIP 

/ 

Service 


I  Module  I  <- -Protocol -->  |  Module  | 
+ - +  + - + 

\  / 

+ - + 

1  Communication  Service  j 
+ - + 


Interface 


Message  Service 
Figure  1. 

The  User /Message  Service  Interface 

The  service  the  message  delivery  system  provides  is  to  accept 
messages  conforming  to  a  specified  format,  to  attenpt  to  de.liver 
those  messages,  and  to  r^ort  on  the  success  or  failure  of  the 
delivery  attenpt.  This  service  is  provided  in  the  context  of  an 
interconnected  system  of  networks  and  may  involve  relaying  a  message 
through  several  intermediate  MPMs  via  different  communication 
services . 
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The  Message/Communication  Service  Interface 

The  message  delivery  system  calls  on  a  communication  service  to 
transfer  information  from  one  MPM  to  another.  There  may  be 
different  communication  services  used  between  different  pairs  of 
MPMs,  though  all  communication  services  must  meet  the  service 
characteristics  described  below. 

It  is  assumed  that  the  communication  service  provides  a  reliable 
two-way  data  stream.  Such  a  data  stream  can  usually  be  obtained  in 
computer  networks  from  the  transport  level  protocol^  for  exanple, 
the  Transmission  Control  Protocol  (TCP)  [3]  .  In  any  case,  the 
properties  the  communication  service  must  provide  are: 

o  Logical  connections  for  two  way  simultaneous  data  flow  of 
arbitrary  data  (i.e.,  no  forbidden  codes)  .  All  data  sent  is 
delivered  in  order. 

o  Sinple  commands  to  open  and  close  the  connections,  and  to  send 
and  receive  data  on  the  connections. 

o  Controlled  flow  of  data  so  that  data  is  not  transmitted  faster 
that  the  receiver  chooses  to  consume  it  (on  the  aver  age)  . 

o  Transmission  errors  are  corrected  without  user  notification  or 
involvement  of  the  sender  or  receiver.  Conplete  breakdown  on 
communication  is  reported  to  the  sender  or  receiver. 

The  Message-Message  Protocol 

The  protocol  used  between  the  distributed  modules  of  the  message 
delivery  system,  that  is,  the  MPMs,  is  a  small  set  of  commands  which 
convey  requests  and  replies ,  These  commands  are  encoded  in  a  highly 
structured  and  rigidly  specified  format. 

2.4.  Mechanisms 

MPMs  are  processes  which  use  some  communication  service.  A  pair  of 
MPMs  which  can  communicate  reside  in  a  common  interprocess 
communication  environment.  An  MPM  mi^t  exist  in  two  (or  more) 
Interprocess  communication  environments,  and  such  an  MPM  might  act  to 
relay  messages  between  MPMs.  Messages  may  be  held  for  a  time  in  an 
MPM;  the  total  path  required  for  delivery  reed  not  be  available 
simultaneously . 

From  the  time  a  message  is  accepted  from  a  UIP  by  an  MPM  until  it  is 
delivered  to  a  UIP  by  an  MPM  and  an  acknowledgment  is  returned  to  the 
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originating  UIP^  the  message  is  considered  to  be  active  in  the  message 
system. 

er  User 

\  / 

UIP  UIP 

\  / 


Message  Service  with  Internal  Relaying 
Figure  2. 

It  should  be  clear  that  there  are  two  roles  an  MPM  can  play,  an 
end-point  MPM  or  a  relay  MPM,  Most  MPMs  will  play  both  roles.  A 
relay  ME^  acts  to  relay  messages  from  one  communication  environment  to 
another.  An  end-point  MEW  acts  as  a  source  or  destination  of 
messages . 

Ihe  transfer  of  data  between  UIPs  and  MPMs  is  viewed  as  the  exchange 
of  data  structures  which  encode  messages.  The  transfer  of  data 
between  MPMs  is  also  in  terms  of  the  transmission  of  structured  data. 
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+ - +  DATA  + - + 

USER— >  I  UIP  1-->S1RUCTURES— >1  MPM  |-->othor 
+ - +  + - ^  ^ - +  MPMs 


+-I 

I  - 

+-I 

I 

+- 


+ - +  q^TA  + - + 

other— > I  MPM  | -->S1RUCTURES— >|  UIP  |— >USER 
MPMs  + - +  + - - + 

I  I 
I  * . 

I 

I  ^ - + 

^-1  I 

I  I 


Message  Flow 
Figure  3. 

In  the  following,  a  message  will  he  described  as  a  structured  data 
object  represented  in  a  particular  kind  of  typed  data  elements,  this 
is  how  a  message  is  presented  when  transmitted  between  MPMs  or 
exchanged  between  an  MPM  and  a  UIP.  Internal  to  an  MPM  (or  a  UIP) .  a 
message  may  be  represented  in  any  convenient  form. 
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2.5.  Relation  to  Other  Protocols 

This  protocol  the  benefited  from  the  earlier  work  on  message  protocols 
in  the  ARPA  Network  [5, 6, 7, 8, 9],  and  the  ideas  of  others  about  the 
design  of  coaputer  message  systems 
[10,11, 12,13, 14, 15, 16, 17, 18, 19, 20, 21] . 

Figure  4  illustrates  the  place  of  the  message  protocol  in  the  ARPA 
internet  protocol  hierarchy: 


f - - -f 

{Telnetl  |  FTP  i  IMessagej 

♦ - T 

1 Voice 1  ... 

1 

1 

Application  Level 

1  / 

1 

1 

1  TCP  1 

1  RIP  1  ... 

▲  M  ^  mm 

1 

*  •  •  •  ▼ 

1 

Host  Level 

1 

1 

1 

.  -  A 

I  Internet  Protocol  |  Gateway  Level 


I  Local  Network  Protocol  |  Network  Level 
- - - - — 


Protocol  Relationships 
Figure  4. 

Note  that  ** local  network**  means  an  individual  or  specific  network. 

For  exas|)le,  the  ARPANET  is  a  local  network. 

Ihe  message  protocol  interfaces  on  one  side  to  user  interface  programs 
and  on  the  other  side  to  a  reliable  transport  protocol  such  as  TCP. 

In  this  internet  message  system  the  MPMs  coarntnicate  directly  using 
the  lower  level  transport  protocol.  In  the  old  ARPANET  system, 
message  transmission  was  pmrt  of  the  file  transfer  protocol. 
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^ - +  + - + 

|Telnet|  |  FTP  |- 
+ - +  + - + 

\  / 

+ - +  + - ^ 

IVoicej---!  NCP  I 
+ - +  - ^ 


+ - + 

*  1 Message | 


I 


+ - + 

1  AEtPA  NET  I 
+ - + 


Application  Level 


Host  Level 


Gateway  Level 


Network  Level 


Old  ARPANET  Protocols 
Figure  5. 

Note  that  in  the  old  ARPANET  protocols  one  can't  send  messages  (or 
conmuriicate  in  any  way)  to  other  networks  since  it  has  no  gateway 
level  or  internet  protocol  [5] ♦ 
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3.  DETAILED  SPECIFICATION 

Tlie  presentation  of  the  information  in  this  section  is  difficult  since 
everything  depends  on  everything,  and  since  this  is  a  linear  medium  it 
has  to  come  in  some  order.  In  this  attenpt,  a  brief  overview  of  the 
message  structure  is  given,  the  detail  of  the  message  is  presented  in 
terms  of  data  objects,  the  various  data  objects  are  defined,  and  finally 
the  r^res^tation  of  the  data  elements  is  specified.  Several  aspects 
of  the  message  structure  are  based  on  the  NSW  Transaction  Protocol  [22] , 
and  similar  (but  more  general)  proposals  [23,24]. 

3.1.  Overview  of  Message  Structure 

A  message  is  normally  conposed  of  three  parts;  the  identification, 
the  command,  and  the  document.  Each  part  is  in  turn  conposed  of  data 
objects . 

Ihe  identification  part  is  conposed  of  a  transaction  number  assigned 
by  the  originating  MPM  and  the  MPM  identifier. 

The  command  part  is  composed  of  an  operation  type,  an  operation  code, 
the  arguments  to  the  operation,  error  information,  the  destination 
mailbox,  and  a  trace.  The  trace  is  a  list  of  the  MPMs  that  have 
handled  this  message. 

The  document  part  is  a  data  structure.  The  message  delivery  system 
does  not  depend  on  the  contents  of  the  document  part.  A  standard  for 
the  docuxKsnt  part  is  defined  in  reference  [25] . 

The  following  sections  define  the  r^^presentation  of  a  message  as  a 
structured  object  conposed  of  other  objects.  Objects  in  tum  are 
represented  using  a  set  of  basic  data  elements. 

The  basic  data  elements  are  defined  in  section  3.7,  In  summary,  these 
are  exact  forms  for  representing  integers,  strings,  boo  leans,  et 
cetera.  There  are  also  two  elements  for  building  data  structures: 
list  and  property  list.  Lists  are  simple  lists  of  elements.  Including 
lists.  Property  lists  are  lists  of  pairs  of  elements,  where  the  first 
element  of  each  pair  names  the  pair.  That  is,  a  property  list  is  a 
list  of  <name,value>  pairs.  In  general,  when  an  object  is  composed  of 
multiple  Instances  of  a  simpler  object  it  is  represented  as  a  list  of 
the  simpler  objects.  When  an  object  is  composed  of  a  variety  of 
simpler  objects  it  is  r presented  as  a  property  list  of  the  simpler 
objects.  In  most  uses  of  the  property  list  representation,  the 
presence  of  <name,value>  pairs  in  addition  to  those  specifically 
required  is  permitted. 
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3.2.  Message  Structure 

An  internet  message  is  conposed  of  two  or  three  parts.  Ihe  first  is 
the  Identification  which  identifies  the  transaction;  the  second  is  tiie 
Command;  and  the  optional  third  part  is  the  Document. 

When  shipped  between  two  MPMs,  a  message  will  take  the  form  of  a 
pr<^rty  list,  with  the  <name,value>  pairs  in  this  order. 

MESSAGE  is: 

(  Identification,  Command  [,  Document  ]  ) 

It  is  convenient  to  batch  several  messages  together,  shipping  them 
as  a  unit  from  one  MPM  to  another.  Such  a  group  of  messages  is 
called  a  message-bag. 

A  message-bag  will  be  a  list  of  Messages;  each  Message  is  of  the 
form  described  above. 

MESSAGE-BAG  is: 

(  Message,  Message.  ...  ) 

Ihe  Identification 

This  is  the  transaction  identifier.  It  is  assigned  by  the 
originating  MPM.  Ihe  identification  is  conposed  of  the  MPM 
identifier,  and  a  transaction  number  unique  in  that  context  for  this 
message . 

Ihe  Command 

Ihe  command  is  composed  of  a  mailbox,  an  operation  code,  the 
arguments  to  that  operation,  some  error  information,  and  a  trace  of 
the  route  of  this  message.  Ihe  command  is  inplemented  by  a  property 
list  which  contains  <name,value>  pairs,  where  the  names  are  used  to 
identify  the  associated  argument  values. 

The  Document 

The  document  portion  of  an  internet  message  is  optional  and  when 
present  is  a  data  structure  as  defined  in  [25] . 
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3.3.  Identi f ication 

Each  message  must  have  a  unique  identifier  while  it  exists  in  the 
message  delivery  system.  This  is  provided  by  the  combination  of  the 
unique  identifier  of  the  MPM  and  a  unique  transaction  number  chosen 
for  the  message  by  this  MPM. 

IDENTIFICATION  is: 

(  npm- identifier,  transaction-number  ) 

The  mpm- identifier  is  based  on  the  host  address  of  the  conputer  in 
which  the  MPM  resides.  If  there  is  more  than  one  MPM  in  a  host  the 
npm- identifier  must  be  extended  to  distinguish  between  the  co-resident 
MPMs. 


3.4.  Command 

This  section  describes  the  commands  MPMs  use  to  communicate  between 
themselves.  The  commands  come  in  pairs,  with  each  request  having  a 
corresponding  reply. 

C0^t1AND  is: 

(  mailbox,  (^ration,  [arguments,] 

[error-class,  error -string, ]  trace  ) 

The  mailbox  is  the  "To"  specification  of  the  message.  Mailbox  is  a 
property  list  of  general  information,  some  of  \rtiich  is  the  essential 
Information  for  delivery,  and  some  of  vrtiich  could  be  extra  information 
which  may  be  helpful  for  delivery.  Mailbox  is  different  from  address 
in  that  address  is  a  very  specific  property  list  without  extra 
information.  The  mailbox  includes  a  specification  of  the  user,  when 
a  command  is  addressed  to  the  MPM  itself  (rather  than  a  user  it 
serves)  the  special  user  name  "*MPM*"  is  specified. 

The  operation  is  the  name  of  the  operation  or  procedure  to  be 
performed. 

The  arguments  to  the  operation  vary  from  operation  to  operation. 

The  error  information  is  composed  of  a  error  class  code  and  a 
character  string,  and  Indicates  what,  if  any,  error  occurred.  The 
error  information  is  normally  present  only  in  replies,  and  not  present 
in  requests. 


Postel 


[Page  15] 


5-889 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE  1985 


August  1980 

Internet  Message  Protocol 
Spec! f ication 


The  trace  is  a  list  of  the  MPMs  that  have  handled  the  message.  Each 
ME^  must  add  its  handling- stamp  to  the  list. 
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3.4.1.  Command:  DELIVER 

function:  Sends  a  document  to  a  mailbox, 
reply:  The  reply  is  ACKNOWLEDGE, 
arguments : 

type- of -service:  one  or  more  of  the  following: 

"REGULAR"  regular  delivery 
"FORWARD"  message  forwarding 
"GENDEL"  general  delivery 
"PRIORITY"  priority  dedivery 

3.4.2.  Command :  ACKNOWLEDGE 

function:  R^ly  to  DELIVER. 
argumenJ’.s: 

reference:  the  identifier  of  the  originating  message, 
address : 

The  address  is  the  final  mailbox  the  message  was  delivered  to. 
Ihis  would  be  different  from  the  original  mailbox  if  the  message 
was  forwarded,  and  is  limited  to  the  tsssential  information 
needed  for  delivery. 

type- of -service:  one  of  the  following: 

"GENDEL"  message  was  accepted  for  general  delivery 

"REGULAR"  message  was  accepted  for  normal  delivery 

"PRIORITY"  message  was  acc^ted  for  priority  delivery 

error-class : 
err or -string: 

If  the  document  v/as  delivered  successfully,  the  error 
information  has  clc^ss  0  and  string  "ok".  Otherwise,  the  error 
information  has  a  non-zero  class  and  the  string  would  be  one  of 
"no  such  user",  "no  such  host",  "no  such  network",  "address 
ambiguous",  or  a  similar  response. 

trail:  the  trace  from  the  DELIVER  command. 
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3.4.3.  Command:  PROBE 

function:  Finds  out  if  specified  mailbox  (specified  in  mailbox  of 
the  command)  exists  at  a  host. 

reply:  The  r^ly  is  RESPONSE. 

arguments :  none . 

3.4.4.  Command :  RESPONSE 
function:  R^ly  to  PROBE, 
arguments: 

reference:  the  identification  of  the  originating  PROBE. 

address:  a  specific  address. 

error-class : 
error -string: 

If  the  mailbox  was  found  the  error  class  is  0  and  the  error 
string  is  ”0K".  If  the  mailbox  has  moved  and  a  forwarding 
address  in  known  the  error  class  is  1  and  the  error  string  is 
"Mailbox  moved,  see  address".  Otherwise  the  error  class  is 
greater  than  1  and  the  error  string  may  be  one  of  the  following: 
"Mailbox  doesn’t  exist",  "Mailbox  full",  "Mailbox  has  moved,  try 
the  new  location  indicated  in  the  address" . 

trail:  the  trace  which  came  from  the  originating  PROBE. 


[Page  18] 


Postel 


3-892 


APPENDIX 


RFC  759 


August  1980 


Internet  Message  Protocol 
Spec! f ication 


3.4.5.  Command :  CANCEL 


function:  Abort  request  for  specified  transaction, 
reply:  Hie  reply  is  CANCELED, 
arguments : 

reference:  identification  of  transaction  to  be  cariceled. 

3.4.6.  Command :  CANCELED 
function:  Reply  to  CANCEL, 
arguments : 

reference:  identification  of  canceled  transaction. 

error -class : 

error -string: 

If  the  command  was  canceled  the  error  class  is  0  and  the  error 
string  is  ”0K" .  Otherwise  the  error  class  is  positive  and  the 
error  string  may  be  one  of  the  following:  "No  such  transaction", 
or  any  error  for  an  unreachable  mailbox. 

trail:  the  trace  of  the  CANCEL  command. 


To  summarize  again,  a  command  generally  consists  of  a  property  list  of 
the  following  objects: 


name 


value 


mailbox 

operation 

arguments 

error-class 

error -string 

trace 


property  list  of  address  information 
name  of  operation 

numeric  class  of  the  error 
text  description  of  the  error 
list  (  handling- stanp,  .  .  .  ) 


3.5.  Document 


The  actual  document  follows  the  command.  The  message  delivery  system 
does  not  depend  on  the  document,  examine  it,  or  use  it  in  any  way. 

The  standard  for  the  contents  of  the  document  is  reference  [25] .  The 
document  must  be  the  last  <name,value>  pair  in  the  message  property 
list. 
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3.6.  Message  Objects 

In  the  composition  of  messages,  we  use  a  set  of  objects  such  as 
mailbox  or  date.  Ihese  objects  are  encoded  in  basic  data  elements. 
Some  objects  are  simple  things  like  integers  or  character  strings, 
other  objects  are  more  complex  things  built  up  of  lists  or  property 
lists. 

Ihe  following  is  a  list  of  the  objects  used  in  messages.  The  object 
descriptions  are  in  alphabetical  order. 

Action 

The  type  of  handling  action  taken  by  the  MPM  when  processing  a 
message.  One  of  ORIGIN,  RELAY,  FORWARD,  or  DESTINATION. 

Address 

Address  is  intended  to  contain  the  minimum  information  necessary  to 
deliver  a  message,  and  no  more  (compare  with  mailbox)  . 

An  address  is  a  property  list.  An  address  contains  the  following 
<name,value>  pairs: 

name  description 


NET  network  name 

HOST  host  name 

USER  user  name 

or : 

name  description 


MPM  mpm- identifier 

USER  user  name 

Answer 

A  yes  (true)  or  no  (false)  answer  to  a  question. 

Arguments 

Many  operations  require  arguments,  which  differ  from  command  to 
command.  This  ’’object"  is  a  place  holder  for  the  actual  arguments 
when  commands  are  described  in  a  general  way. 
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City 

Hie  character  string  name  of  a  cit>'. 

Command 

(mailbox,  operation  [  ,  arguments  ] 

[  , error-class,  error-string  ],  trace) 


Country 

Hie  character  string  name  of  a  country. 

Date 

Hie  date  and  time  are  r^resented  according  to  the  International 
Standards  Organization  (ISO)  recommendations  [26,27,28].  Taken 
together  the  ISO  recommendations  2014,  3307,  and  4031  result  in  the 
following  r^resentation  of  the  date  and  time: 

yyyy-mm- dd-hh :  mm :  ss ,  f  f  f +hh :  mm 

Viiiere  yyyy  is  the  four-digit  year,  mm  is  the  two-digit  month,  dd  is 
the  two-digit  day,  hh  is  the  two-digit  hour  in  24  hour  time,  mm  is 
the  two-digit  minute,  ss  is  the  two-digit  second,  and  fff  is  the 
decimal  fraction  of  the  second.  To  this  basic  date  and  time  is 
appended  the  offset  from  Greenwich  as  plus  or  minus  hh  hours  and  mm 
minutes . 

The  time  is  local  time  and  the  offset  is  the  difference  between 
local  time  and  Coordinated  Universal  Time  (UTC)  .  To  convert  from 
local  time  to  UTC  algebraically  subtract  the  offset  from  the  local 
time. 


For  exaiqple,  when  the 
Los  Angeles 
the  UTC  is 


time  in 

is  14:25:00-08:00 
22:25:00 


or  when  the  time  in 
Paris  is 
the  UTC  is 


11:43:00+01:00 

10:43:00 


Document 

Hie  document  is  the  user's  conposition  and  is  not  used  by  the 
message  delivery  system  in  any  way. 
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Error -Cl ass 

A  numeric  code  for  the  class  of  the  error.  The  error  classes  are 
coded  as  follows: 

=  0:  indicates  success,  no  error. 

This  is  the  normal  case. 

=  1:  failure,  address  changed. 

This  error  is  used  when  forwarding  is  possible,  but  not  allowed 
by  the  type  of  service  specified. 

=  2:  failure,  resources  unavailable. 

These  errors  are  temporary  and  the  command  they  re^ond  to  may 
work  if  attempted  at  a  later  time. 

=  3:  failure,  user  error. 

For  example,  unknown  operation,  or  bad  arguments. 

=  4:  failure,  MPM  error.  Recoverable. 

These  errors  are  temporary  and  the  command  they  respond  to  may 
work  if  attempted  at  a  later  time. 

=  5:  failure,  MPM  error.  Permanent. 

These  errors  are  permanent,  there  is  no  point  in  trying  the  same 
command  again. 

=  6:  Aborted  as  requested  by  user. 

The  response  to  a  successfully  canceled  command. 
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Error -String 

This  is  a  character  string  describing  the  error.  Possible  errors: 


error -string  error -cl ass 

No  errors  0 
Ok  0 
Mailbox  Moved,  see  address  1 
Mailbox  Full,  try  again  later  2 
Syntax  error,  operation  unrecognized  3 
Syntax  error,  in  arguments  3 
No  Such  User  3 
No  Such  Host  3 
No  Such  Network  3 
No  Such  Transaction  3 
Mailbox  Does  Not  Exist  3 
Ambiguous  Address  3 
Server  error,  try  again  later  4 
No  service  available  5 
Command  not  inplemented  5 
Aborted  as  requested  by  user  6 


Handl  ing- Stamp 

Ttie  handl  ing- stamp  indicates  the  MPM,  the  date  (including  the  time) 
that  a  message  was  processed  by  an  MPM,  and  the  type  of  handling 
action  taken. 

(  npm- identifier,  date,  action  ) 

Host 

The  character  string  name  of  a  host. 

Identification 

This  is  the  transaction  identifier  associated  with  a  particular 
message.  It  is  tlie  transaction  number,  and  the  MPM  identifier  of 
the  originating  MPM. 

(  npm- identifier,  transact ion-ntanber  ) 
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Internet  Address 

This  identifies  a  host  in  the  ARPA  internetwork  environment.  When 
used  as  a  part  of  identification,  it  identifies  the  originating  host 
of  a  message.  The  internet  address  is  a  32  bit  number,  the  higher 
order  8  bits  identify  the  network,  and  the  lower  order  24  bits 
identify  the  host  on  that  network  [2]  .  For  use  in  the  MPMs  the 
internet  address  is  divided  into  eight  bit  fields  and  the  value  of 
eacl:  field  is  represented  in  decimal  digits.  For  example,  the 
ARPANET  address  of  ISIE  is  16V837748  and  is  r^resented  as 
10,1,0,52.  FurUvar,  this  representation  may  be  extended  to  include 
an  address  within  a  host,  such  as  the  TCP  port  of  the  MPM,  for 
example,  10,1,0,52,0,45. 

Mailbox 

This  is  the  destination  address  of  a  user  of  the  internetwork  mail 
system.  Mailbox  contains  information  such  as  network,  host, 
location,  and  local  user  irxientifier  of  the  recipient  of  the 
message.  Soma  information  contained  in  mailbox  may  not  be  necessary 
for  delivery. 

As  an  example,  when  mie  sends  a  message  to  someone  for  the  first 
time,  he  may  Include  many  items  %rtiich  are  not  necessary  simply  to 
insure  delivery.  Ho%#ever,  once  he  gets  a  reply  to  this  message,  the 
reply  will  contain  an  Address  (as  opposed  to  Mailbox)  which  may  be 
used  from  then  on. 

A  mailbox  is  a  property  list.  A  mailbox  might  contain  the 
following  <name,value>  pairs: 

name  description 


MPM  apm*  identifier 

NET  network  name 

HOST  host  name 

PORT  address  of  MPM  within  the  host 

USER  user  name 

ORG  organization  name 

CITY  city 

STATE  state 

COUNTRY  country 

ZIP  zip  code 

PHONE  phone  number 

The  minimum  mail  box  is  an  Address. 
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MPM- Identifier 

Ihe  internetwork  address  of  the  MPM.  This  may  be  the  ARPA  Internet 
Address  or  an  X.121  Public  Data  Network  Address  [29]  .  The 
npoa- identifier  is  a  property  list  vrtiich  has  one  <naiiie,valiie>  pair. 
This  ’jnusual  structure  is  used  so  that  it  will  be  easy  to  determine 
the  type  of  address  used. 

Network 

This  character  string  name  of  a  network. 

Operation 

This  names  the  operation  or  procedure  to  be  performed.  It  is  a 
character  string  name. 

Organization 

This  character  string  name  of  a  organization. 

Phone 

This  character  string  name  representation  of  a  phone  number.  For 
example  the  phone  number  of  ISI  is  1  (international  regio^)  +  213 
(area  code)  +  822  (central  office)  +  1511  (station  number)  = 
12138221511, 

Port 

This  names  the  port  or  subaddress  within  a  host  of  the  MPM.  The 
default  port  for  the  MPM  is  45  (55  octal)  [4] . 

Reference 

The  reference  is  an  identification  from  an  earlier  message. 

State 

The  character  string  name  of  a  state. 
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'frace 

Each  MPM  that  handles  the  message  must  add  its  handling- staiDp  to 
this  list.  This  will  allow  detection  of  messages  being  sent  in  a 
loop  within  the  internet  mail  system,  and  aid  in  fault  isolation. 

Trail 

When  a  message  is  sent  tlirough  the  internetwork  environment,  it 
acquires  this  trace,  a  list  of  MPMs  that  have  handled  the  message. 
This  list  is  then  carried  as  the  trail  in  a  reply  or  acknowledgment 
of  that  message.  Requests  and  replies  always  have  a  trace  and  each 
MPM  adds  its  handling- stanp  to  this  trace.  Replies,  in  addition, 
have  a  trail  which  is  the  conplete  trace  of  the  original  message. 

Transaction  Number 

This  is  a  number  which  is  uniquely  associated  with  this  transaction 
by  the  originating  MPM.  It  Identifies  the  transaction.  (A 
transaction  is  a  message  and  acknowledgment.)  A  transaction  number 
must  be  unique  during  the  time  which  the  message  (a  request  or 
reply)  containing  it  could  be  active  in  the  network. 

Type- o  f- Service 

A  service  parameter  for  the  delivery  of  a  message,  for  instance  a 
message  could  be  delivered  (REGULAR) ,  forwarded  (FORWARD) ,  turned 
over  to  general  delivery  (GENDEL)  (i.e.,  allow  a  person  to  decide 
how  to  furtlier  attenpt  to  deliver  the  message) ,  or  require  priority 
handling  (PRIORITY)  . 

User 

The  character  string  name  of  a  user. 

XI 21  Address 

This  identifies  a  host  in  the  Public  Data  Network  anviroTiment .  When 
used  as  a  part  of  identifier,  it  identifies  the  originating  host  of 
a  message.  The  X121  address  is  a  sequence  of  up  to  14  digits  [29]  . 
For  use  in  the  MPMs  the  X121  address  is  represented  in  decimal 
digits . 
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Zip  Code 

The  character  string  representation  of  a  postal  zip  code.  The  zip 
code  of  ISI  is  90291. 

3.7.  Data  EleKits 

The  data  elcecnts  defined  here  are  similar  to  the  data  structure  and 
encoding  used  In  NSIf  [30]  . 

Each  of  the  diagrams  idildi  follow  represent  a  sequence  of  octets. 

Field  boiMidaries  are  denoted  by  the  **  |  **  character,  octet  boundaries  by 
the  character.  Each  element  begins  with  a  one-octet  code.  The 
order  of  the  Information  in  each  element  is  left-to-rlg^t .  In  fields 
with  numeric  values  the  hlgh'order  (or  most  significant)  bit  Is  the 
left-most  bit.  For  transmission  purxx>ses,  the  leftmost  cxrtet  is 
traramlttad  first.  Cohen  has  descnrlbed  some  of  the  difficulties  in 
mapping  memory  order  t:o  transmission  orcJer  [31]  . 


Code  Type  Representation 


0  Mo  Operation 


g 


P. 


Padding 


octet  count 


I  Data 


y - + - + - + - 1- - 


2  Bcmlean 


!  -  I  1/0  I 

+ - + - + 


-f - + - + - + 

3  Index  |  3  |  Data  | 


4  Integer 


Postal 
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5  Precision 
Integer 


h - + - + - + - 

I  octet  count  |  Data  , 

I- - + - + - + - 


6  Bit  String 


- + - + - + - 

I  bit  count  I  Data  . 

h - + - + - + - 


7  Name  String  |  7  |  count  |  Data  .  . . 

+ - + - + - 


8  Text  String 


I  8  I  octet  count  |  Data 
+ - + - + - + - + - 


9  List 


I  9  I 

+ - +- 


octet  count 


10  Proplist 


octet  count  |  Data 

- + - + - 


11  End  of  List 


+ - + 

I  11  I 

+ - + 


Element  code  0  (NOP)  is  an  empty  data  element  used  for  padding  when  it 
is  necessary.  It  is  ignored. 

Element  code  1  (PAD)  is  used  to  transmit  large  amounts  of  data  with  a 
message  for  test  or  padding  purposes.  The  type-octet  is  followed  by  a 
three-octet  count  of  the  number  of  octets  to  follow.  No  action  is 
taken  with  this  data  but  the  count  of  dummy  octets  must  be  correct  to 
indicate  the  next  element  code. 

Element  code  2  (BOOLEAN)  is  a  boolean  data  element.  The  octet 
following  the  t^^-octet  has  the  value  1  for  True  and  0  for  False. 
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Element  code  3  (INDEX)  is  a  16-bit  unsigned  integer  datum.  Element 
code  3  occupies  only  3  octets. 

Element  code  4  (INTEGER)  is  a  signed  32-bit  integer  datum.  This  will 
always  occupy  five  octets.  Representation  is  two's  complement. 

Element  code  5  (EPI)  is  an  extended  precision  integer.  The  type  octet 
is  followed  by  a  three-octet  count  of  the  number  of  data  octets  to 
follow.  Representation  is  two's  conplement. 

Element  code  6  (BITSTR)  is  a  bit  string  element  for  binary  data.  The 
bit  string  is  padded  on  the  ric^it  with  zeros  to  fill  out  the  last 
octet  if  the  bit  string  does  not  end  on  an  octet  boundary.  This  data 
type  must  have  the  bit -count  in  the  three -octet  count  field  instead  of 
the  number  of  octets. 

Element  code  7  (NAME)  is  used  for  the  representation  of  character 
string  names  (or  other  short  strings)  .  Hie  type  octet  is  followed  by 
a  one -octet  count  of  the  number  of  characters  (one  per  octet)  to 
follow.  Seven  bit  ASCII  characters  are  used,  rigfit  justified  in  the 
octet.  The  high  order  bit  in  the  octet  is  zero. 

Element  code  8  (TEXT)  is  used  for  the  r^resentation  of  text.  The 
type  octet  is  followed  by  a  three- octet  count  of  the  number  of 
characters  (one  per  octet)  to  follow.  Seven  bit  ASCII  characters  are 
used,  right  justified  in  the  octet.  The  hic^i  order  bit  in  the  octet 
is  zero. 

Element  code  9  (LIST)  can  be  used  to  create  structures  composed  of 
other  elements.  The  three-octet  octet  count  specifies  the  number  of 
octets  in  the  whole  list  (i.e.,  the  number  of  octets  following  this 
count  field  to  the  end  of  the  list,  not  including  the  ENDLIST  octet) . 
The  two-octet  item  count  contains  the  number  of  elements  which  follow. 
Any  element  may  be  used  including  list  itself. 


octet  count 


item  count 


repeated  | 
+- 


element 


-/— + 


I  ENDLIST) 


In  some  situations  it  may  not  be  possible  to  know  the  length  of  a  list 
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until  the  head  of  it  has  been  transmitted.  To  allow  for  this  a 
special  ENDLIST  element  is  defined.  A  list  of  undetermined  length  is 
transmitted  with  the  octet  count  cleared  to  zero,  and  the  item  count 
cleared  to  zero.  A  null  or  empty  List,  one  with  no  elements,  has  an 
octet  count  of  two  (2)  and  an  item  count  of  zero  (0)  .  The  ENDLIST 
element  always  Toilows  a  LIST,  even  when  the  lengtdi  is  determined. 

Element  code  10  (PROPLIST)  is  the  Property  List  element.  It  is  a 
special  case  of  the  list  element,  in  which  the  elements  are  in  pairs 
and  the  first  element  of  each  pair  is  a  name.  It  has  the  following 
form; 


+ - + - + - + - ^ - + 

I  10  I  octet  count  |  pair  \ 

+ - + - + - + - + - + 

+ - + - /---+ - ^ - /---+ 

repeated  (  name  element  |  value  element  | 

. + - /— ■" - - /— + 

+' - + 

I ENDLIST I 
+ - + 

The  Property  List  structure  consists  of  a  set  of  unordered 
<name,value>  pairs.  The  pairs  are  composed  of  a  name  which  must  be  a 
NAME  element  and  a  value  vhich  may  be  any  kind  of  element.  Following 
the  type  code  is  a  three-octet  octet  count  of  the  following  octets. 
Following  the  octet  count  is  a  one- octet  pair  count  of  tlie  number  of 
<name,value>  pairs  in  the  property  list. 

The  name  of  a  <name,value>  pair  is  to  be  unique  within  the  property 
list,  that  is,  there  shall  be  at  most  one  occurrence  of  any  particular 
name  in  one  property  list. 

In  some  situations  it  may  not  be  possible  to  know  the  length  of  a 
property  list  until  the  head  of  it  has  been  transmitted.  To  allow  for 
this  the  special  ENDLIST  element  is  defined.  A  property  list  of 
undetermined  length  is  transmitted  with  the  octet  count  cleared  to 
zero,  and  the  pair  count  cleared  to  ^ero.  A  null  or  empty  property 
list,  one  with  no  elements,  has  an  octet  count  of  one  (1)  and  an  pair 
count  of  zero  (0)  .  Tlie  FNDLIST  element  always  follows  a  property 
list,  even  when  the  length  is  determined. 

Element  code  11  (EMDLIST)  is  the  end  of  list  element.  It  marks  the 
end  of  the  corresponding  list  or  property  list. 
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Structure  Sharing 

When  messages  are  batched  in  message-bags  for  transmission,  it  may 
often  be  the  case  that  the  same  document  will  be  sent  to  more  than 
one  recipient.  Since  the  document  portion  can  usually  be  esqpected 
to  be  the  major  part  of  the  message,  much  repeated  data  would  be 
sent  if  a  copy  of  the  document  for  each  recipient  were  to  be  shifted 
in  the  message-bag. 

To  avoid  this  redundancy,  messages  may  be  assembled  in  the 
message-bag  so  that  actual  data  appears  on  its  first  occurrence  and 
only  references  to  it  appear  in  later  occurrences.  When  data  is 
shared,  the  first  occurrence  of  the  data  will  be  tagged,  and  later 
locations  where  the  data  should  appear  will  only  reference  the 
earlier  tagged  location.  All  references  to  copied  data  point  to 
earlier  locations  in  the  message-bag.  Ihe  data  to  be  retrieved  is 
indicated  by  the  tag. 

This  is  a  very  general  sharing  mechanism.  PLEASE  NOTE  TEIAT  TEE  MPM 
WILL  NOT  SUPPORT  TEE  FULL  USE  OF  TEnS  MECHANISM.  THE  MPM  WILL  ONLY 
SUPPORT  SHARING  OF  WEK)LE  DOCUMENTS.  No  other  level  of  sharing  will 
be  suqpported  by  the  MPMs. 

HiJ.s  sharing  mechanism  may  be  used  within  a  document  as  long  as  all 
references  refer  to  tags  within  the  same  document. 

Sharing  is  implemented  by  placing  a  share-tag  on  the  first 
occtarrence  of  the  data  to  be  shared,  and  placing  a  share- reference 
at  the  locations  where  copies  of  that  data  should  occur. 


12  Share  Tag 


+ - + - + - + 

I  12  I  share- index  | 

+ - + - - + 


13  Share  Reference  |  13  |  share- index  | 


Element  code  12  (S-TAG)  is  a  share  tag  element.  The  two  octets 
following  the  type-octet  specify  the  shared  data  identification  code 
for  the  following  data  element.  Note  that  s-tag  is  not  a  DATA 
element,  in  the  sense  that  data  eluents  encode  higher  level 
objects. 

Element  code  13  (S-IEI')  is  a  share  reference  element.  The  two 
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octets  following  the  type -octet  specify  the  referenced  shared  data 
identification  code. 


An  exanple  of  using  this  mechanism  is 

(  (  <a>,  <b>  )  (  <c>,  <b>  )  ) 

could  be  coded  as  follows  to  share  <b> 

(  (  <3>,  <s-tag-l><b>  )  (  <c>,  <.s-rof-l>  )  ) 

To  facilitate  working  with  structures  which  may  contain  shared  data, 
the  two  hig^- order  bits  of  the  list  and  property  list  element  codes 
are  reserved  for  indicating  if  the  structure  contains  data  to  be 
shared  or  contains  a  reference  to  shared  data.  That  is,  if  the 
high- order  bit  of  the  list  or  property  list  element  code  octet  is 
set  to  one  then  the  property  list  contains  a  share -reference  to 
shared  data.  Or,  if  the  second  hi^- order  bit  is  set  to  one  the 
structure  contains  a  share- tag  for  data  to  be  shared. 

The  exanple  above  is  now  repeated  in  detail  showing  the  use  of  the 
hi c^- order  bits. 


<a>  I  12 


<b>  11 


9  <c>  13 


11  11 


It  is  not  considered  an  error  for  an  element  to  be  tagged  but  not 
referenced. 

A  substructure  with  internal  sharing  may  be  created.  If  such  a 
substructure  is  closed  with  respect  to  sharing  --  that  is,  all 
references  to  its  tagged  elements  are  within  the  substructure  -- 
then  there  is  no  need  for  the  knowledge  of  the  sharing  to  propagate 
up  the  hierarchy  of  lists.  For  exanple,  if  the  substructure  is: 

00-LIST  (  a  b  c  b  ) 
which  with  sharing  is: 

11-LIST  (  a  Tl:b  c  R1  ) 


When  this  substructure  is  included  in  a  large  structure  the  high 
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‘  order  bits  can  be  reset  since  the  substructure  is  closed  with 

J  respect  to  sharing.  For  example: 

\  00-LIST  (  X  11-LIST  (  a  Tl:b  c  R1  )  y  ) 

.  Note:  While  sharing  adds  transmission  and  memory  efficiency,  it  is 

^  costly  in  processing  to  separate  shared  elements.  This  is  the  main 

'  reason  for  restricting  the  sharing  su^^orted  by  the  MPM.  At  some 

I  later  time  these  restrictions  may  be  eased. 

I  It  is  possible  to  create  loops,  "strange  loops"  and  "tangled 

\  hierarchies"  using  this  mechanism  [32]  .  The  MPM  will  not  check  for 

'  such  improper  structures  within  documents,  and  will  not  deliver 

J  messages  involved  in  such  structures  between  documents. 

If  an  encryption  scheme  is  used  to  ensure  the  privacy  of 
communication  it  is  unlikely  that  any  parts  of  the  message  can  be 
shared.  This  is  due  to  the  fact  that  in  most  case  the  encryption 
keys  will  be  specific  between  two  individuals.  There  may  be  a  few 
cases  where  encrypted  data  may  be  shared.  For  example,  all  the 
members  of  a  committee  may  use  a  common  key  when  acting  on  committee 
business,  or  in  a  public  key  scheme  a  document  may  be  "signed"  using 
the  private  key  of  the  sender  and  inspected  by  anyone  using  the 
public  key  of  the  sender. 


Postel 


[Page  33] 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


1985 


Internet  Message  Protocol 


August  1980 


,  vV 

li  „  • 


[Page  34] 


Postel 


APPENDIX 


RFC  759 


August  1980 


Internet  Message  Protocol 


4.  OTEiER  ISSUES 

This  section  discusses  various  other  issues  that  need  to  be  dealt  with 

in  a  conputer  message  system. 

4.1.  Accounting  and  Billing 

Accounting  and  billing  must  be  performed  by  the  MPM.  The  charge  to 
the  user  by  the  message  delivery  system  must  be  predictable,  and  so 
cannot  depend  on  the  actual  cost  of  sending  a  particular  message  which 
incurs  random  delays,  handling  and  tenporary  storage  charges.  Rather, 
these  costs  must  be  aggregated  and  charged  back  to  the  users  on  an 
average  cost  basis.  The  user  of  the  service  may  be  charged  based  on 
the  destination  or  distance,  the  length  of  the  message,  type  of 
service,  or  other  parameters  selected  as  the  message  is  entered  into 
the  delivery  system,  but  must  not  depend  on  essentially  random 
handling  by  the  system  of  the  particular  message. 

This  means  it  is  pointless  to  have  each  message  carry  an  accumulated 
charge  (or  list  of  charges)  .  Rather,  the  MPM  will  keqp  a  log  of 
messages  handled  and  periodically  bill  the  originators  of  those 
messages . 

It  seems  that  the  most  reasonable  scheme  is  to  follow  the  practice  of 
the  international  telephone  authorities.  In  such  schemes  the 
authority  where  the  message  originates  bills  the  user  of  the  service 
for  the  total  charge.  The  authorities  assist  each  other  in  providing 
the  international  message  transfer  and  the  authorities  periodically 
settle  any  differences  in  accounts  due  to  an  imbalance  in 
international  traffic. 

Thus  the  MPMs  will  ke^  logs  of  messages  handled  and  will  pjeriodically 
charge  their  neighboring  MPM  for  messages  handled  for  them.  This 
settlement  procedure  is  outside  the  message  system  and  between  the 
administrators  of  the  MPMs. 


As  traffic  grows  it  will  be  inpractical  to  log  every  message 
Individually.  It  will  be  necessary  to  establish  categories  of 
messages  (e.g.,  short,  medium,  large)  and  only  count  the  number  in 
each  category. 

The  MPM  at  the  source  of  the  message  will  have  a  local  means  of 
identifying  the  user  to  charge  for  the  message  delivery  service.  The 
relay  and  destination  MPMs  will  know  which  neighbor  MPMs  to  charge  (or 
settle  with)  for  delivery  of  their  messages. 
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4.2.  Addressing  and  Routing 

The  mailbox  provides  for  many  types  of  address  information.  The  MPMs 
in  the  ARPA  internet  can  most  effectively  use  the  internet  address 
[2]  .  The  use  of  other  address  information  is  not  yet  very  clear. 

Some  thoughts  on  addressing  issues  may  be  found  in  the  references 
[33,34,35]  . 

An  MPM  sometimes  must  make  a  routing  decision  vhen  it  is  acting  as  a 
relay-MPM  (or  source  MPM)  .  It  must  be  able  to  use  the  Information 
from  the  mailbox  to  determine  to  v^ch  of  its  neighbor  MPMs  to  send 
the  message.  One  way  this  might  be  inplemented  is  to  have  a  table  of 
destination  networks  with  corresponding  neig^ibor  MPM  identifiers  to 
use  for  routing  toward  that  network. 

It  is  not  expected  that  such  routing  tables  would  be  very  dynamic. 
Changes  would  occur  only  when  new  MPMs  came  into  existence  or  MPMs 
went  out  of  service  for  periods  of  days. 

Even  with  relatively  slowly  changing  routing  information  the  MPMs  need 
an  automatic  mechanism  for  adjusting  their  routing  tables.  The 
routing  problem  here  is  quite  similar  to  the  problem  of  routing  in  a 
network  of  packet  switches  such  as  the  ARPANET  IMPS  or  a  set  of 
internet  gateways.  A  great  deal  of  work  has  been  done  on  such 
problems  and  many  simple  schemes  have  been  found  faulty.  There  are 
details  of  these  procedures  which  may  become  troublesome  when  the 
number  of  nocUis  grows  beyond  a  certain  point  or  the  frequency  of 
update  exchancfes  gets  largo. 

A  basic  routing  scheme  is  to  have  a  table  of  <network-'name, 
iipm-identifier>  pairs.  The  MPM  could  look  up  the  network  name  found 
in  the  mailbox  of  the  message  and  determine  the  internet 
npm- identifier  of  the  next  MPM  to  which  to  route  the  message.  To 
permit  automatic  routing  uqpdates  another  column  would  be  added  to 
indicate  the  distance  to  the  destination.  This  could  be  measured  in 
several  ways,  for  example,  the  number  of  relay  MPM  (or  hops)  to  the 
final  destination.  In  this  case  each  entry  in  the  table  is  a  triple 
of  <network-name,  npm- Identifier,  distance>. 

To  update  the  routing  information  when  changes  occur  an  MPM  updates 
its  table.  It  then  sends  to  each  next  MPM  in  its  table  a  table  of 
pairs  <network-naine,  dlstance>,  which  say  in  effect  "I  can  get  a 
message  to  each  of  these  networks  with  "cost"  distance."  An  MPM  which 
receives  such  an  update  will  add  to  all  the  distances  the  distance  to 
the  MPM  sending  the  update  (e.g.,  one  hop)  and  conpare  the  information 
with  its  own  table. 


[Page  36] 


Postel 


3-910 


APPENDIX 


RFC  759 


August  1980 


Internet  Message  Protocol 
Other  Issues 


If  the  update  information  shows  that  the  distance  to  a  destination 
network  Is  now  smaller  via  the  MPM  which  sent  tlie  update,  the  MPM 
changes  Its  own  table  to  reflect  the  better  route,  and  the  new 
distance.  If  the  MPM  has  made  changes  In  Its  table  It  sends  update 
Information  to  all  the  MPMs  listed  as  next-MPMs  In  Its  table. 

One  further  feature  Is  that  when  a  new  network  comes  Into  existence  an 
entry  must  be  added  to  the  table  In  each  MPM.  The  MPMs  should 
therefore  expect  the  case  that  update  information  may  contain  entries 
which  are  new  networks,  and  In  such  an  event  add  these  entries  to 
their  own  tables. 

When  a  new  MPM  comes  Into  existence  It  will  have  an  Initial  table 
Indicating  that  It  Is  a  good  route  (short  distance)  to  the  network  It 
Is  in,  and  will  have  entries  for  a  few  nel^^ibor  networks.  It  will 
send  an  Initial  "i^xlate"  to  those  neighbor  MPMs  which  will  respond 
with  more  complete  tables,  thus  Informing  the  new  MPM  of  routes  to 
many  networks. 

This  routing  update  mechanism  Is  a  simple  minded  scheme  and  may  have 
to  be  replaced  as  the  system  of  MPMs  gro%fs.  In  addition  It  Ignores 
the  opportunity  for  MPMs  to  use  other  Information  (besides  destination 
network  name)  for  routing.  MPMs  may  have  tables  that  Indicate 
next-MPMs  based  on  city,  telephone  number,  organization,  or  other 
categories  of  Information. 

4.3.  Encryption 

It  Is  straightforward  to  add  the  capability  to  have  the  document 
portion  of  messages  either  wholly  or  partially  encrypted.  An 
additional  basic  data  element  Is  defined  to  carry  encrypted  data.  The 
data  within  this  element  may  be  composed  of  other  elements,  but  that 
could  only  be  perceived  after  the  data  was  decrypted. 


4. - 4. - ^ - ^ - 4. 

14  Encrypt  |  14  |  octet  count  | 

- ♦ - ^-----.4.- - 4. 

4 - 4 - .4__-__-4 - 

ialg  id]  key  id  j  Data  ... 

4 - 4 - 4 - 

Element  code  14  (ENCRYPT)  is  used  to  encapsulate  encrypted  data.  The 
format  is  the  one- octet  type  code,  the  three- octet  octet  count,  a 
one-octet  algorithm  identifier,  a  two-octet  key  identifier,  and  count 
octets  of  data.  Use  of  this  element  indicates  that  the  data  it 
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contains  is  encrypted.  The  encryption  scheme  is  indicated  by  the 
algorithm  identifier,  and  the  key  used  is  indicated  by  the  key 
identifier  (this  is  not  the  key  itself) .  Ihe  NBS  Data  Encryption 
Standard  (DES)  [36],  public  key  encryption  [37,38,39],  or  other 
schemes  may  be  used. 

To  process  this  data  eleoient,  the  user  is  asked  for  the  appropriate 
key  and  the  data  can  then  be  decrypted.  The  data  thus  revealed  will 
be  in  the  form  of  complete  data  element  fields.  Encryption  cannot 
occur  over  a  partial  field.  The  revealed  data  is  then  processed 
normally. 

Note  that  there  is  no  reason  why  all  fields  of  a  document  could  not  be 
encrypted  including  all  document  hea^r  information  such  as  From, 

Date,  etc. 


[Page  38] 


Postal 


3-912 


APPENDIX 


RFC7S9 


August  1980 


Internet  Message  Protocol 


5.  TEIE  MPM:  A  POSSIBLE  ARCHITECIURE 

The  heart  of  the  internet  message  system  is  the  ICM  i4iich  is  responsible 
for  routing  and  delivering  messages.  Each  network  Kust  have  at  least 
one  MPM.  These  MPMs  are  logically  connected  together,  and  internet  mall 
is  always  transferred  along  logical  channels  between  them.  The  mis 
interface  with  existing  local  message  systems. 

Since  the  local  message  system  may  be  very  different  from  this  internet 
system,  special  programs  may  be  necessary  to  convert  incoming  internet 
messages  to  the  local  format.  Likewise,  messages  outgoing  to  other 
networks  may  be  converted  to  the  internet  format  and  sent  via  the  ms. 

5.1.  Inter  faces 

User  Interface 

It  Is  assumed  that  the  interface  between  the  and  the  UIP 
provides  for  passing  data  structures  idilch  represent  the  document 
portion  of  the  message.  In  addition,  this  interface  must  pass  the 
delivery  address  information  (which  becomes  the  information  in  the 
mailbox  field  of  the  command)  .  It  is  assumed  that  the  information 
is  passed  between  the  UIP  and  the  MPM  via  shared  files,  but  this  is 
not  the  only  possible  mechanism.  These  two  processes  may  be  more 
strongly  coupled  (e .  g . ,  by  sharing  memory)  ,  or  less  strongly  coi^led 
(e .  g . ,  by  communicating  via  logical  channels)  . 

When  a  UIP  passes  a  document  and  a  destination  address  to  the  l®=M, 
the  MPM  assigns  a  transaction-number  and  forms  a  message  to  send. 

The  MPM  must  record  the  relationship  between  the  transact ion-rember. 
the  document,  and  the  UIP,  so  that  it  can  inform  the  UIP  about  the 
outcome  of  the  delivery  attempt  for  that  document  when  the 
acknowledgment  message  is  received  at  some  later  time. 

Assuming  a  file  passing  mode  of  communication  between  the  UIP 
the  MPM  the  sending  and  receiving  of  mail  mig^it  involve  the 
following  interactions: 

A  user  has  an  interactive  session  with  a  UIP  to  conpose  a  doam^t 
to  send  to  a  destina'uion  (or  list  of  destinations)  .  When  the  user 
indicates  to  the  UIP  that  the  document  is  to  be  sent,  the  UIP 
places  the  information  into  a  file  for  the  ME>M.  The  UIP  may  ther^ 
turn  to  the  next  request  of  the  user*. 

The  MPM  finds  the  file  and  extracts  the  the  iiiionration.  ’'t 
creates  a  message,  assigning  a  transaction-number  and  fonp.ing  a 
deliver  command.  The  MPM  records  the  UIP  associated  with  this 
message.  The  MPM  sends  the  message  toward  the  destination. 
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When  the  MPM  receives  a  deliver  message  from  another  MPM  addressed 
to  a  user  in  its  domain,  it  extracts  the  document  and  puts  it  into 
a  file  for  the  UIP  associated  with  the  destination  user.  The  MPM 
also  sends  an  acknowledge  message  to  the  originating  MPM. 

When  the  MPM  receives  an  acknowledgment  for  a  message  it  sent,  the 
MPM  creates  a  notification  for  the  associated  UIP  and  places  it  in 
a  file  for  tliaC  UIP. 

The  format  of  these  files  is  vp  to  each  UIP/MPM  interface  pair. 

One  reasonable  choice  is  to  use  the  same  data  structures  used  in 
the  MPM-MPM  communication. 

Communication  Interface 

It  is  assumed  here  that  the  MPMs  use  an  underlying  communication 
system,  and  TCP  [3]  has  been  tak«n  as  the  model.  In  particular,  the 
MPM  is  assumed  to  be  listening  for  a  TCP  connection  on  a  TCP  port, 
i.e.,  it  is  a  server  process.  The  port  is  either  given  explicitly 
in  the  npm- identifier  or  takes  the  default  vaule  45  (55  octal)  [4]  . 
Again,  this  is  not  intended  to  limit  the  inplementation  choices,’ 
other  forms  of  interprocess  communication  are  allowed,  and  other 
types  of  physical  interconnection  are  permitted.  One  might  even  use 
dial  tel^hone  calls  to  interconnect  MPMs  (using  suitable  protocols 
to  provide  reliable  communication)  [12,19,20,21]. 


5.2.  The  MPM  Organization 

Messages  in  the  internet  mail  systan  are  transmitted  in  lists  called 
message-bags  (or  simply  bags) ,  each  bag  containing  one  or  more 
messages.  Each  MPM  is  expected  to  inplement  functions  which  will 
allow  it  to  deliver  local  messages  it  receives  and  to  forward 
non-local  ones  to  other  MPMs  presumably  closer  to  the  message's 
destination. 

Loosely,  each  MPM  can  be  separated  into  six  components: 

1-  -Acceptor 

Receives  incoming  message-bags,  from  other  MPMs,  from  UIPs,  or 
from  conversion  programs. 

2-  -Message -Bag  Processor 

Splits  a  bag  into  these  three  portions: 
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a.  Local  Host  Messages 

b.  Local  Net  Messages 

c.  Foreign  Net  Messages 

3-  -Local  Host  Delivery 

Delivers  local  host  messages,  may  call  on  conversion  program. 

4-  -Local  Net  Delivery 

Delivers  local  net  messages,  may  call  on  conversion  program. 

5-  -Foreign  Net  Router 

Forms  message-bags  for  transmission  to  other  MPMs  and  determines 
the  first  step  in  the  route. 

6 - -Foreign  Net  Sender 

Activates  transmission  channels  to  other  MTMs  and  sends 
message-bags  to  foreign  MPMs. 

If  the  local  net  message  system  uses  the  protocol  of  Uie  MPMs,  then 
there  need  be  no  distinction  between  local  net  and  foreign  net 
delivery  procedures. 

All  of  these  components  can  be  thought  of  as  independent.  The 
function  of  the  Acceptor  is  to  await  incoming  message-bags  and  to 
Insert  them  into  the  Bag- Input  Queue. 

The  Bag- Input  queue  is  read  by  the  message-bag  Processor  which  will 
separate  and  deliver  suitable  portions  of  the  message-bags  it 
retrieves  from  the  queue  to  one  of  three  queues: 

a.  Local  Host  Queue 

b.  Local  Net  Queue 

c.  Foreign  Net  Queue 

When  an  MPM  has  a  message  to  send  to  another  MPM,  it  must  add  its  own 
handling -starp  to  the  trace  field  of  the  command.  The  trace  then 
becomes  a  record  of  the  route  the  message  has  taken.  An  MPM  should 
examine  the  trace  field  to  see  if  the  message  is  in  a  routing  loop. 
All  commands  require  the  return  of  the  trace  as  a  trail  in  the 
matching  reply  command. 

All  of  these  queues  have  as  elements  conplete  message-bags  created  by 
selecting  messages  from  the  input  message -bags . 
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The  Local  Host  queue  serves  as  input  to  the  Local  Host  Delivery 
process.  This  conponent  is  responsible  for  delivering  messages  to  its 
local  host.  It  may  call  on  a  conversion  program  to  reformat  the 
messages  into  a  form  the  local  protocol  will  acc^t.  This  will 
probably  involve  such  things  as  copying  shared  information. 

The  Local  Net  queue  serves  as  input  to  the  Local  Net  Delivery  process. 
This  conponent  is  responsible  for  delivering  messages  to  other  hosts 
on  its  local  net.  It  must  be  capable  of  handling  whatever  error 
conditions  the  local  net  mi^^t  return,  and  should  include  the  ability 
to  retransmit.  It  may  call  on  a  conversion  program  to  reformat  the 
messages  into  a  form  the  local  protocol  will  accept.  This  will 
probably  involve  such  things  as  copying  shared  information . 

The  other  two  processes  are  more  closely  coupled.  The  Foreign  Net 
Router  takes  its  irput  bags  from  the  Foreign  Net  Queue.  From  the 
internal  information  it  contains,  it  determines  which  of  the  MPMs  to 
which  it  is  connected  should  receive  the  bag. 

It  then  places  the  bag  along  with  the  routing  information  into  the 
Send  Mail  Queue.  The  Foreign  Net  Sender  retrieves  it  from  that  queue 
and  trarvsmits  it  across  a  channel  to  the  intended  foreign  MPM.  The 
Sender  aggregates  messages  to  the  same  next  MPM  into  a  bag. 

The  Foreign  Net  Router  should  be  capable  of  receiving  external  input 
to  its  routing  information  table.  This  may  come  from  the  Foreign  Net 
Sender  in  the  case  of  a  channel  going  down,  requiring  a  decision  to 
either  postpone  delivery  or  to  determine  a  new  route.  The  Router  is 
responsible  for  maintaining  sufficient  information  to  determine  where 
to  send  any  incoming  message-bag. 

Forwarding 

An  MPM  may  have  available  information  on  the  correct  mailboxes  of 
users  which  are  not  at  its  location.  This  information,  called  a 
forwarding  data  base,  may  be  used  to  return  the  correct  address  in 
response  to  a  probe  command,  or  to  actually  forward  a  deliver 
command  (if  allowed  by  the  type  of  service)  . 

Because  such  forwarding  may  cause  the  route  of  a  message  to  pass 
throu^  an  MPM  already  on  the  trace  of  this  message,  only  the 
portion  of  the  trace  back  to  the  most  recent  forward  action  should 
be  used  for  loqp  detection  by  a  relay  relaying  MPM,  and  only  the 
forward  action  entries  in  the  trace  should  be  checked  by  a 
forwarding  ME^. 


[Page  42] 


Postel 


3-Q16 


APPENDIX 


RFC  759 


August  1980 

Internet  Message  Protocol 


Inplementatlon  Recoimnendiatlons 

Transaction  numbers  can  be  assigned  sequentially,  with  wrap  around 
ii^en  the  highest  value  is  reached.  This  should  ensure  that  no 
message  with  a  particular  transaction  number  from  this  source  is  in 
the  network  when  another  instance  of  this  transaction  number  is 
chosen. 

The  processing  to  separate  shared  elements  when  the  routes  of  the 
shared  elements  diverge  while  still  preserving  the  sharing  possible 
appears  to  be  an  0(N*M**2)  operation  where  N  is  the  number  of 
distinct  objects  in  a  message  which  may  be  shared  across  message 
boundaries  and  M  is  the  number  of  messages  in  the  bag. 

Also  note  that  share-tags  may  be  copied  into  separate  message  bags 
which  are  not  refercfficed.  These  could  be  removed  with  another  pass 
over  the  message  bag. 
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6.  EXAMPLES  &  SCENARIOS 


Exanple  1:  Message  Format 


Si^pose  we  want  to  send  the  following  message: 


Date:  1979-03-29-11:46-08:00 
From:  Jon  Postel  <Postel@ISIE> 
Subject:  Meeting  Thursday 
To;  Danny  Cohen  <Cohen^SC-ISIB> 
CC :  Linda 


Danny; 


Please  mark  your  calendar  for  our  meeting  Thursday  at  3  pm. 


--Jon. 


It  will  be  encoded  in  the  structured  format.  The  following  will 
present  successive  stops  in  the  top  down  generation  of  this  message. 
The  actual  document  above  will  not  be  shown  in  the  coded  form. 


1 .  message 


(identification,  command,  document) 


(ID:  (npm- identifier,  transaction-number) , 
CMD:  (MAILBOX .‘mailbox,  OPERATION: operation. 


DOC : <  <document >  > ) 


arguments,  TRACE: trace) 


(ID: (npm- identifier,  transaction-number) , 

CMD:  (MAILBOX :mailbox,  OPERATION: operation, 

TYPE - OF - SERVI CE : regul ar ,  TRACE : trace) 

DOC : <<document>>) 


(ID:  (MPM:  (lA:  12, 1, 0.  52, 0, 45) ,  TRANSACTION:  37)  , 
CMD:  (MAILBOX:  (MPM:  (lA:  12,  3,  0, 52, 0, 45)  , 
NET:ARPA, 

HOST:ISIB, 

PORT: 45, 

USER  .‘Cohen) , 

OPERATION:DELIVER, 

TYPE  -  OF  -  SERVI  CE ;  REGULAR , 

TRACE:  (MPM:  (lA:  12, 1,  0,  52, 0, 45) 

DATE: 1979-03-29-11:46-08: 00, 
ACTION:ORIGIN)) , 

DOC : <<document>>) 
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6.  PROPLIST:  ( 

ID:PROPLIST:  ( 

MPM: PROPLIST:  ( 

IA:12,1,0,52,0,45), 

ENDLIST 

TEiANSACTI0N:37) 

ENDLIST, 

CMD:  PROPLIST  ( 

MAILBOX:  (PROPLIST:  ( 

MPM:PROPLIST( 

IA:12,3,0,52,0,45)  , 
ENDLIST 
NET:ARPA, 

H0ST:ISIB, 

PORT: 45, 

USER : Cohen  ) , 

ENDLIST 

OPERATION.-DELIVER, 

TYPE-OF-SERVICE  :REGULAR, 

TRACE:  (PROPLIST: MPM: 

(PROPLIST: 

IA:12,1,0,52,0,45) 

ENDLIST 

DATE : 1979-03-29-11:46-08 : 00, 
ACTION : ORIGIN)  ) , 

ENDLIST 

ENDLIST 

DOC :  «document») 

ENDLIST 
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Exanple  2:  Delivery  and  Acknowledgment 

The  following  are  four  views  of  the  message  of  example  1  during  the 
successive  transmission  from  the  origination  MPM,  throu^  a  relay  MPM, 
to  the  destination  MPM,  and  the  return  of  the  acknowledgment,  throu^ 
a  relay  MPM,  to  the  originating  MPM. 


+ - + 

I  A  B  I 

\  sending  — >  originating  — >  relay  — >  destination  receiving  | 

user  MPM  MPM  MPM  user 


I  DC  I 
I  originating  <--  relav  < —  destination  j 
I  MPM  MPM‘  MPM  I 
+ - + 


Transmission  Path 
Figure  6. 
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A.  Between  the  originating  MPM  and  the  relay  MPM. 

PROPLIST: 

NAME; "ID", 

PROPLIST; 

NAME;"iyPM", 

PROPLIST; 

NAME;"IA",  NAME;"10,1,  0,52,0,45" 

ENDLIST 

NAME; "TRANSACTION",  INTEGER; 37 
ENDLIST 
NAME;"CMD", 

PROPLIST; 

NAME;  "MAILBOX", 

PROPLIST; 

NAME;  "MPM", 

PROPLIST; 

NAME;"IA",  NAME; "10, 3, 0, 52, 0,45" 

ENDLIST 

NAME; "NET",  NAME:"ARPA" 

NAME; "HOST",  NAME;"ISIB" 

NAME; "PORT",  NAME; "45" 

NAME; "USER",  NAME; "Cohen" 

ENDLIST 

NAME  .‘"OPERATION",  NAME ;  "DELI  VER" 
NAME;"TYPE-OF-SERVICE",  NAME ;  "REGULAR" 

NAME;  "TRACE", 

LIST; 

PROPLIST; 

NAME:  "MPM", 

PROPLIST: 

NAME:"IA",  NAME; "10, 1, 0, 52, 0, 45" 

ENDLIST 

NAME; "DATE",  NAME: "1979-03-29-11:47. 5-00: 00" 
NAME: "ACTION",  NAME : "ORIGIN" 

ENDLIST 

ENDLIST 

ENDLIST 

NAME: "DOC",  «document» 

ENDLIST 
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B.  Between  the  relay  MPM  and  the  destination  MPM. 

PROPLIST: 

NAME: "ID", 

PROPLIST: 

NAME: "MPM", 

PROPLIST: 

NAME:"IA",  NAME: "10, 1,0, 52, 0,45" 

ENDLIST 

NAME: "TRANSACTION",  INTEGER: 37 
ENDLIST 
NAME:"CMD", 

PROPLIST: 

NAME  .-"MAILBOX", 

PROPLIST: 

NAME:  "MPM", 

PROPLIST: 

NAt4E:"IA",  NAME:"10,  3,0,52,  0,45" 

ENDLIST 

NAME  .-"NET",  NAME:"ARPA" 

NAME: "HOST",  NAME:"ISIB" 

NAME: "PORT",  NAME: "45" 

NAME:  "USER",  NAME  .-"Cohen" 

ENDLIST 

NAME:"OPERATI(W",  NAME :  "DELIVER" 
NAME:"TYPE-OF-SERVICE",  NAME :  "REGULAR" 

NAME:  "TRACE", 

LIST: 

PROPLIST: 

NAME:  "MPM", 

PROPLIST: 

NAME:"IA",  NAME: "10, 1, 0, 52, 0,45" 

ENDLIST 

NAME: "DATE",  NAME: "1979-03-29-11:47 .5-08:00" 
^4AME: "ACTION".  NAME : "ORIGIN" 

ENDLIST 

PROPLIST: 

NAME:  "MPM", 

PROPLIST: 

NAME:"IA",  NAME: "10, 2, 0. 52, 0. 45" 

ENDLIST 

NAME: "DATE",  NAME: "1979-03-29-11:40-08: 00" 
NAME: "ACTION".  NAME : ’*RELAY" 

ENDLIST 

ENDLIST 

ENDLIST 

NAME: "DOC".  «document» 
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ENDLIST 

C.  Between  the  destination  MPM  and  the  relay  MPM. 

PROPLIST: 

NAME:”ID*\ 

PROPLIST: 

NAME:  "MPM", 

PROPLIST: 

NAME:''IA*',  NAME:  "10,  3, 0, 52, 0, 45" 

ENDLIST 

HAME:"mANSACriW,  INTEGER:  1993 
ENDLIST 
NAME:  "CM3", 

PROPLIST: 

NAME:  "MAILBOX", 

PROPLIST: 

NAME: '•MPM", 

PROPLIST: 

NAME :  '‘lA" ,  INTEGER :  "10, 1 , 0 , 52 , 0 , 45" 
ENDLIST 

NAME  .‘"NET*,  NAME:''ARPA" 

NAME:*1*)ST",  NAME:"ISIE" 

NAME:"PC]Rr*,  NAME:**45" 

NAME:**USER",  NAME:"*MPM*" 

ENDLIST 

NAME: "OPERATION",  NAME : "ACKNOWLEDGE" 
NAME:"REFEPJENCE", 

PRC»»LIST: 

NAME:  "MPM", 

PROPLIST: 

NAME:"IA",  NAME: "10, 1,0,52,0,45" 
ENDLIST 

NAME:"TRANSACTIC3I'*,  INTEGER: 37 
ENDLIST 

NAME: "ADDRESS", 
pRca>Lisr: 

NAME:  "MPM", 

PROPLIST: 

NAME:"iA",  INTECSR: "10, 3, 0, 52, 0, 45" 
ENDLIST 

NAME; "USER".  NAME: "Cohen" 

E?E)LIST 

NAME:’TyPE-OE-SERVICE".  NAME :  ••RECRJLAR" 

NAME: "ERROR-CLASS",  INDEX :0 
NAME:"ERROR-SIRI^K;",  NAME: "Ok” 

NAME:  "TRAIL", 
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LIST: 

PROPLIST: 

NAME:''MPM”, 

PROPLIST: 

NAME:'*IA*',  NAME: '*10, 1,  0, 52,  0, 45" 

ENDLIST 

NAME : "DATE" ,  NAME : "1979«03- 29-11 : 47 . 5-08 : 00" 
NAME:"ACTIC»J",  NAME  .‘"ORIGIN" 

ENDLIST 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME:"IA",  NAME: "10, 2,  0, 52, 0,45" 

ENDLIST 

NAME: "DATE",  NAME; "1979-03-29-11:48-08: 00" 
NAME: "ACTION",  NAME: "RELAY" 

ENDLIST 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME:"IA",  NAME: "10, 3, 0,52, 0,45" 

ENDLIST 

NAME : "DATE" ,  NAME : "1979-03-29-11 : 51 . 567-08 : 00" 
NAME:"ACriC»l",  NAME :  "DESTINATI(»I" 

ENDLIST 
ENDLIST 
NAME ‘."TRACE", 

LIST: 

PROPLIST: 

NAME: ‘71PM", 

PROPLIST: 

NAME:"IA",  NAME: "10, 3,  0, 52, 0, 45" 

ENDLIST 

NAME: "DATE",  NAME: ”1979-03-29-11: 52-08: 00" 
NAME: "ACTION",  NAME : ”C»ICIN" 

ENDLIST 

ENDLIST 

ENDLIST 

ENDLIST 
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D.  Between  the  relay  MPM  and  the  originating  MPM. 

PROPLIST: 

MAME:"ID'\ 

PROPLIST: 

NAME:  "MPM**, 

PROPLIST: 

NAME:**IA’*,  NAME:”10,3,0,52,0,45*‘ 

ENDLIST 

I  NAME: •'TRANSACTION",  INrEGER:1993 

I  ENDLIST 

NAME:  "a©", 

PROPLIST: 

NAME:  "MAILBOX", 

PROPLIST: 

NAh.i::"MPM", 

PJ.QPLIST: 

NAME:"IA",  INrEGER:"10, 1, 0, 52, 0, 45" 

ENDLIST 

NAME: "NET",  NAME:*‘ARPA" 

NAME: ••HOST",  NAME:"ISIE" 

NAME  .‘"PORT",  NAME:  "45" 

NAME: "USER",  NAME:"*MPM*" 

ENDLIST 

NAME: "OPERATION",  NAME : "ACKNOWLEDGE" 

NAME:  "REFERENCE", 

PROPLIST: 

NAME:  "MPM", 

PROPLIST: 

NAME:"IA",  NAME: "10, 1,0, 52,  0,45" 

ENDLIST 

NAME: "TRANSACTION",  INTEGER: 37 
ENDLIST 

NAME;  "ADDRESS", 

PRC»>LIST: 

NAME:  "MPM", 

PROPLIST: 

NAME:"IA",  INTEGER: "10, 3,0,52,0,45" 

ENDLIST 

NAME  .-"USER",  NAME;  "Cohen” 

ENDLIST 

NAME:"TTPE-CF-SERVICE",  NAME ; "REGULAR’’ 

NAME: "ERROR-CLASS",  INDEX :0 
NAME; "ERROR-STRING",  NAME 
NAME:  "TRAIL", 

LIST: 

PROPLIST; 
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NAME:"MPM*\ 

PROPLIST: 

HAME:'*10,1,0,52,0,45“ 

r^DLISr 

MAME : "DATE” ,  MAME : "1979-03-29-11 : 47 . 5-08 : 00" 
NAME  .‘"ACTION",  NAME :  "ORIGIN" 

ENDLIST 

PROPLIST; 

NAME:"MPM", 

PROPLIST: 

NAME;"IA",  NAME: "10,  2,  0,52,  0,45" 

ENDLIST 

NAME : "DATE" ,  NAME : "1979-03-29-11 : 48-08 : 00" 
NAME: "ACTION",  NAME: "RELAY" 

ENDLIST 

PROPLIST: 

NAME:"MPM", 

PROPLIST* 

NAME:"iA",  NAME:"10,3,0,52,0,45" 

ENDLIST 

NAME : "DATE" ,  NAME : "1979-03-29-11 : 51 . 567-08 : 00" 
NAME: "ACTION",  NAME ; "DESTINATION" 

ENDLIST 
ENDLIST 
NAME:  "TRACE", 

LIST: 

PROPLIST: 

NAME:'*M?M", 

PROPLIST: 

NAME;"IA",  NAME : "10, 3, 0, 52, 0,45" 

ENDLIST 

NAME: "DATE",  NAME: "1979-03-29-11: 52-08: 00" 
NAME: "ACTION",  NAME: "C»IGIN" 

ENDLIST 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME:"IA",  NAME: "10, 2, 0, 52, 0, 45" 

ENDLIST 

NAME : "DATE" ,  NAME : "1979-03-29-11 : 52 , 345-08 ; 00" 
NAME  .‘"ACTION",  NAME :  **RELAY" 

ENDLIST 

ENDLIST 

ENDLIST 

ENDLIST 
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7 .  SPECIFICATION  SUMMARY 


7.1.  Message  Fields 

All  keywords  used  in  this  protocol  are  to  be  recognized  independent  of 
case. 

action:  NAME  (one  of) 

"ORIGIN"  I  "RELAY"  |  "FORWARD"  |  "DESTINATION" 

address:  PROPLIST  (one  of) 

NAME:  "MPM",  <iipn-identifier> 

NAME:  "USER",  <user> 

or 


NAME: 

"NET",  <net> 

NAME: 

"HOST", 

<host> 

NAME: 

"PORT", 

<port> 

NAME: 

"USER", 

<user> 

answer : 

BOOLEAN 

V: 


city:  NAME 

command:  PROPLIST 

NAME:  "MAILBOX",  <mailbox> 
NAME:  "OPERATION",  <operation> 
«arguments» 


NAME 

NAME 

NAME 


"ERROR-CLASS",  <error-class> 
"ERROR-STRING",  <error-string> 
"TRACE",  <trace> 


(only  in  replies) 
(only  in  replies) 


country:  NAME 
document :  < <document » 
error-class:  INDEX 
error-string:  NAME 
host:  NAME 
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handling-stanp:  PROPLIST 


NAME 

NAME 

NAME 


"MPM",  <npm“identifier> 
"DATE”,  <date> 

"ACTION",  <action> 


identification;  LIST 

NAME:  "MPM",  <iipn-identifier> 

NAME :  "TRANSACTION" ,  <transaction-nuinber> 


internet -address;  NAME 


mailbox:  PROPLIST  (some  of) 
NAME :  "MPM" ,  cnpoa-  identi  f ier> 
NAME:  "NET",  <net> 

NAME:  "H)ST",  <host> 

NAME:  "PORT",  <port> 

NAME:  "USER",  <user> 

NAME ;  "ORG" ,  <organi2atlon> 
NAME:  "CITY",  <city> 

NAME;  "STATE",  <state> 

NAME:  "COUNTRY",  <country> 
NAME:  "ZIP",  <zlp-code> 

NAME:  "PHONE",  <phone -number > 
«other  -  i  tems» 


message:  PROPLIST 

NAME:  "ID",  <ldentificatlon> 

NAME :  "CMD" ,  <conimand> 

NAME;  "DOC",  <document>  (only  in  deliver) 
mpm- identifier:  PROPLIST  (one  of) 

NAME:  "lA",  < internet- address > 


or 


NAME:  "X121",  <xl21-address> 
net:  NAME 


operation:  NAME  (one  of) 

"DELIVER"  I  "ACKNOWLEDGE 
I  "PROBE"  I  "RESPONSE 
I  "CANCEL"  I  "CANCELED" 

organization:  NAME 

phone-nuniber ;  NAME 
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port;  NAME 

state:  NAME 

trace:  LIST 

<handl  ing- St  aiBp> 

trail:  LIST 

<handl  ing-  staiBp> 

transactlon-nuBBber :  INTEGER 

type-of-service:  NAME  (one  or  more  of) 

“REGULAR"  I  "FORWARD"  1  "GENDEL"  |  "PRIORITY" 

user:  NAME 

xl21-address:  NAME 

zip-code:  NAME 
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7.2.  Deliver  Message 

PROPLIST: 

NAME: "ID", 

PROPLIST: 

NAME:"MPM’', 

PROPLIST; 

NAME :  ”  lA" ,  NAME :  < internet  -address > 

ENDLIST 

NAME: "TRANSACTION”,  INTEGER : <transaction-nuiDber> 
ENDLIST 
NAME:"CMD", 

PROPLIST: 

NAME:  "MAILBOX", 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME :  "lA" ,  INTEGER :  < internet- address > 
ENDLIST 

NAME: "NET",  NAME:<net> 

NAME: "HOST",  NAME:<host> 

NAME  .-"PORT",  NAME:<port> 

NAME: "USER",  NAME:<user> 

NAME :  "ORG" ,  NAME :  <organization> 

NAME: "cm",  NAME;<city> 

NAME: "STATE",  NAME:<state> 

NAME: "COUNTRY",  NAME : <country> 

NAME: "ZIP",  NAME:<zip-code> 

NAME: "PHONE",  NAME : <phone-nuxnber> 

«other  -  items» 

ENDLIST 

NAME; "OPERATION",  NAME ; "DELI VER" 
NAME;"TYPE-OF-SERVICE",  NAME;<type -of-service> 
NAME:  "TRACE", 

LIST: 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME : " I A" ,  INTEGER : < internet -addr ess > 
ENDLIST 

NAME: "DATE".  NAME:<date> 

NAME: "ACTION",  NAME :< act ion> 

ENDLIST 

ENDLIST 

ENDLIST 

NAME: "DOC".  «document» 

ENDLIST 
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7.3.  Acknowledge  Message 

PROPLIST: 

NAME:  "ID", 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME : "  lA" ,  NAME :  < internet- address > 

ENDLIST 

NAME:"1RANSACTI0N",  INTEGER :  <transaction-nuiDber> 
ENDLIST 
NAME:"CMD", 

PROPLIST: 

NAME:  "MAILBOX", 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME :  "lA" ,  INTEGER : < internet- address > 
ENDLIST 

NAME: "USER",  NAME:"*MPM*" 

NAME: "NET",  NAME:<net> 

NAME: "PORT",  NAME:<port> 

NAME: "HOST",  NAME:<host> 

ENDLIST 

NAME: "OPERATION",  NAME : "ACKNOWLEDGE" 

NAME:  "REFERENCE", 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME : "  lA" ,  NAME :  < internet- address > 

ENDLIST 

NAME :  '"IRANSACTION" ,  INTEGER :  <transaction-nuinber> 
ENDLIST 

NAME: "ADDRESS", 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME : " lA" ,  INTEGER : < internet- address > 
ENDLIST 

NAME: "USER",  NAME:<user> 

ENDLIST 

NAME :  "TYPE-OF-SERVICE" ,  NAME :  <type-of-service> 

NAME: "ERROR-CLASS",  INDEX: <orror-clas5> 

NAME: "ERROR-STRING",  NAME : <error-string> 

NAME:  "TRAIL", 

LIST: 

PROPLIST: 

NAME:"MPM". 
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PROPLIST: 

NAME :  "lA” ,  INTECTU : <intemet-address> 
ENDLZST 

NAME; "DATE",  NAME;<date> 

NAME; "ACTION",  NAME ; Oct ion> 

ENDLIST 

ENDLIST 

NAME;"IRACE", 

LIST; 

PROPLIST; 

NAME;"MPM", 

PROPLIST; 

NAME ; " lA" ,  INTEGER : < internet- address > 
ENDLIST 

NAME; "DATE",  NAME;<date> 

NAME  .‘"ACTION",  NAME;Oction> 

ENDLIST 


ENDLIST 

ENDLIST 

ENDLIST 
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7.4.  Probe  Message 

PROPLIST: 

NAME: "ID", 

PROPLIST: 

NAME:”MPM'\ 

PROPLIST: 

NAME : "  I  A”  ^  NAME :  <intemet-  address> 

ENDLIST 

NAME :  '’IRA’^SACriON" ,  INTEGER :  <transaction-nuinber> 
ENDLIST 
NAME:"CMD", 

PROPLIST: 

NAME:  "MAILBOX", 

PROPLIST: 

NAME:"MPM", 

PROPLIJ3T: 

NAME : "  lA" ,  INTEGER :  < internet- address > 
ENDLIS'.r 

NAMEi'^NEr",  NAME:<net> 

NAME: "HOIST",  NAME:<host> 

NAME: "PORT",  NAME:<port> 

NAME: "USER",  NAME:<user> 

NAME :  "ORG" ,  NAME :  <organization> 

NAME -."CITY",  NAME:<city> 

NAME:"S7ATE",  NAME:<state> 

NAME:"a)UNTRY",  NAME :  <country> 

NAME: "ZIP",  NAME:<zip-code> 

NAME :  "PHONE" ,  NAME :  <phone -number > 

«other  -  items» 

ENDLIST 

NAME:"OPER>\TION",  NAME: "PROBE" 

NAME:  "TRACE", 

LIST: 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME : " lA" ,  INTEGER : < internet- address > 
ENDLIST 

NAME: "DATE",  NAME:<date> 

?^AME: "ACTION",  NAME : <action> 

ENDLIST 

ENDLIST 

ENDLIST 

ENDLIST 
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7.5.  Ressponse  Message 

PROPLIST: 

NAME: "ID", 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME:"IA",  NAME:<intemet-address> 

ENDLIST 

NAME :  "TRANSAlCTION"  ,  INTEGER :  <transaction-nuinber> 
ENDLIST 
NAME:"CMD", 

PROPLIST: 

NAME:  "MAILBOX", 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME : "  I  A" ,  INTEGER :  <  internet- address  > 

ENDLIST 

NAME: "NET",  NAME:<net> 

NAME: "HOST",  NAME:<host> 

NAME: "PORT",  NAME:<port> 

NAME: "USER",  NAME;"*MPM*" 

ENDLIST 

NAME: "OPERATION",  NAME : "RESPONSE" 

NAME  .-"REFERENCE", 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME:"IA",  NAME :< internet -addross> 

ENDLIST 

NAME :  "TRANSACTION" ,  INTEGER :  <transaction-nuiBber> 
ENDLIST 

NAME: "ADDRESS", 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME : " lA" ,  INTEGER : <internet-address> 
ENDLIST 

NAME: "USER",  NAME:<user> 

ENDLIST 

NAME: "ERROR-CLASS",  INDEX :<error-class> 

NAME; "ERROR-STRING",  NAME ;<error-string> 

NAME -."TRAIL", 

LIS'!: 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 
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NAME:"IA",  I NTEGE3i:< internet -addr ess > 
ENDLIST 

KAME:"DATE",  HAME:<date> 

NAME: "ACTION",  NAME : <actlon> 

ENDLIST 

ENDLIST 
NAME:  "TRACE", 

LIST: 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME:"IA",  I NTECTR:< interne t-addr ess > 
ENDLIST 

NAME: "DATE",  NAME:<date> 

NAME:"ACTIW',  NAME :  <action> 

ENDLIST 

ENDLIST 

ENDLIST 

ENDLIST 
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7.6.  Cancel  Message 

PROPLIST: 

KAME:"ID'*, 

PROPLIST: 

NAME:''MPM'*, 

PROPLIST: 

NAME:"IA'',  HAME:< internet -addross> 

ENDLIST 

NAME :  "TRANSACTION'' ,  INTEGER :  <transactlon-number> 
ENDLIST 
NAME:"a®", 

PROPLIST: 

NAME  .‘"MAILBOX", 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME:"IA",  INTEGER :< interne t-addr ess > 

ENDLIST 

NAME  .‘"NET'*,  NAME:<net> 

NAME  .‘"HOST",  NAME:<host> 

NAME: "PORT",  NAME:<port> 

NAME: "USER",  NAME:<user> 

NAME:"0RC",  NAME :  <organization> 

NAME: "cm",  NAME:<city> 

NAME  .‘"STATE",  NAME:<state> 

NAME: "COUNTRY",  NAME : <country> 

NAME: "ZIP",  NAME:<2ip-code> 

NAME: "PHONE",  NAME:<phone-number> 

«other  -  i  t6o»» 

ENDLIST 

NAME: "OPERATIC",  NAME : "CANCEL" 

NAME: "REFERENCE", 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME:"IA",  NAME :< internet- address> 

ENDLIST 

NAME: "TRANSACTION",  INTEGER: <transactlon-nuinber> 
ENDLIST 
NAME:  "TRACE". 

LIST: 

PROPLIST: 

NAME.‘"MPM". 

PROPLIST: 

NAME: "I A".  INTEGER: < internet -address> 
ENDLIST 

NAME: "DATE",  NAME:<clate> 
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KAME: "ACTION",  NAME : <action> 
ENDLIST 


ENDLIST 

ENDLIST 

ENDLIST 
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7.7.  Canceled  Message 

PROPLIST: 

NAME -."ID", 

PROPLIST; 

NAME;''MPM", 

PROPLIST: 

NAME:"IA",  NAME: < Internet -address> 

ENDLIST 

NAME: "TRANSACTION",  INTEGER :<transactlon-nuinber> 
ENDLIST 
NAME:"CMD", 

PROPLIST: 

NAME:  "MAILBOX", 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME : " lA" ,  INTEGER :  < internet- address > 

ENDLIST 

NAME: "NET",  NAME:<net> 

NAME: 'HOST",  NAME:<host> 

NAME -."PORT",  NAME:<port> 

NAME: "USER",  NAME:"*MPM*" 

ENDLIST 

NAME:"C»>ERATI<»I",  NAME: "CANCELED" 

NAME: "REFERENCE", 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME : "  I  A" ,  NAME :  <lntemet-  address> 

ENDLIST 

NAME :  "TRANSACTION" ,  INTEC^ :  <tr»nsactlon-number > 
ENDLIST 

NAME: "ADDRESS", 

PROPLIST: 

NAME:"MPM", 

PROPLIST: 

NAME:"IA",  INTEGER :< Internet- address> 
ENDLIST 

NAME  .-"USER",  NAME;<user> 

ENDLIST 

NAME: "ERROR-CLASS",  INDEX :<error -class > 
NAME:"ERROR-STRINC",  NAME:<error-string> 
NAME:"IRAIL", 

LIST: 

PROPLIST: 

NAME:"^«>M". 

PROPLIST: 
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NAME:"IA”,  INTEGER :<int^i-net-address> 
ENDLIST 

NAME: "DATE",  NAME:<date> 

NAME: ’’ACTION”,  NAME:<actlon> 

ENDLIST 

ENDLIST 
NAME: ’’TRACE”, 

LIST: 

PROPLIST: 

NAME:”MPM”, 

PROPLIST: 

NAME:"IA”,  INTEGER :<lntemet-addr€K*s> 
ENDLIST 

NAME; "DATE”,  NAME:<date> 

NAME: "ACTION",  NAME :< act ion> 

ENDLIST 

ENDLIST 

ENDLIST 

ENDLIST 
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7.8.  Data  Element  Summary 


CODE 

NAME 

STRUCTURE 

LENGTH 

0 

NOP 

CODE (1) 

1 

1 

PAD 

CODE  (1) ,  COUNT  (3) ,  DATA  (C) 

C+4 

2 

BOOLEAN 

CODE (1) .TRUE-FALSE (1) 

2 

3 

INDEX 

CODE (1) .INDEX  (2) 

3 

4 

INTEGER 

CODE (1)  .INTEGER (4) 

5 

5 

EPI 

CODE  (1)  .  COUNT  (3) .  INTEGER  (C) 

C+4 

6 

BITSTR 

CODE (1) . COUNT (3) . BITS (C/8) 

C/8+4 

7 

NAME 

CODE  (1) ,  COUNT  (1) ,  NAME  (C) 

C+2 

8 

TEXT 

CODE  (1) ,  COUNT  (3)  ,  TEXT  (C) 

C+4 

9 

LIST 

CODE (1)  .COUNT (3) ,  ITEMS  (2)  ,DATA(C-2) 

C+4 

10 

PROPI.IST  CODE(l)  ,COONT(3)  ,PAIRS(1)  ,DATA(C-1) 

C+4 

11 

ENDLIST 

CODE (1) 

1 

12 

S-TAG 

CODE (1) .INDEX (2) 

3 

13 

S-REF 

CODE (1) .INDEX (2) 

3 

14 

ENCRYPT 

CODE(l)  .COUNT (3)  .ALG-ID(l) . 

KEY-ID(2)  .DATA(C-3) 

C+4 

The 

numbers  in 

parentheses  are  the  number  of  octets  in 

the  field 
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POST  OFFICE  PROTOCOL  -  VERSION  2 


Status  of  this  Memo 

This  RFC  suggests  a  simple  method  for  workstations  to  dynamically 
access  mail  from  a  mailbox  server.  This  RFC  specifies  a  preposed 
protocol  for  the  ARPA- Internet  community,  and  requests  discussion  and 
suggestions  for  improvement.  Ihis  memo  is  a  revision  of  RFC  918. 
Distribution  of  this  memo  is  unlimited. 

Introduction 

The  intent  of  the  Post  Office  Protocol  Version  2  (POP2)  is  to  allow  a 
user's  workstation  to  access  mail  from  a  mailbox  server.  It  is 
expected  that  mail  will  be  posted  from  the  workstation  to  the  mailbox 
server  via  the  Simple  Mail  Transfer  Protocol  (SMTP)  .  For  further 
information  see  RFC-821  [1]  and  RFC-822  [2]  . 

This  protocol  assumes  a  reliable  jlata  stream  such  as  provided  by  TCP 
or  any  similar  protocol.  When  TCP  is  used,  the  POP2  server  listens 
on  port  109  [4] . 

System  Model  and  Philosophy 

While  we  view  the  workstation  as  an  Internet  host  in  the  sense  that 
it  inplements  IP,  we  do  not  e^qpect  the  workstation  to  contain  the 
user's  mailbox.  We  esqpect  the  mailbox  to  be  on  a  server  machine. 

We  believe  it  is  important  for  the  mailbox  to  be  on  an  "always  ip" 
machine  and  that  a  workstation  may  be  frequently  powered  down,  or 
otherwise  unavailable  as  an  SMTP  server. 

POP2  is  designed  for  an  environment  of  workstations  and  servers  on  a 
low-delay,  high-throughput,  local  networks  (such  as  Ethernets)  .  POP2 
may  be  useful  in  other  environments  as  well,  but  if  the  environment 
is  substantially  different,  a  different  division  of  labor  between  the 
client  and  server  may  be  appropriate,  and  a  different  protocol 
required. 

Suppose  the  user's  real  name  is  John  Smith,  the  user's  machine  is 
called  FIDO,  and  that  the  mailbox  server  is  called  DOG-HOUSE.  Then 
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we  expect  the  user's  mail  to  be  addressed  to  JSmithtgOOG-HOUSE.ARPA 
(not  JSinith@FIDO.ARPA)  . 

Hiat  is,  the  destination  of  the  mail  is  the  mailbox  on  the  server 
machine.  The  POP2  protocol  and  the  workstation  are  merely  a 
mechanism  for  viewing  the  messages  in  the  mailbox. 

The  user  is  not  tied  to  any  particular  workstation  for  accessing  his 
mail.  The  workstation  does  not  appear  as  ary  pari:  of  the  mailbox 
address . 

This  is  a  very  simple  protocol.  This  is  not  a  user  Interface.  We 
esqpect  that  there  is  a  program  in  the  workstation  that  is  friendly  to 
the  user.  This  protocol  is  not  "user  friendly".  One  basic  rule  of 
this  protocol  is  "if  anything  goes  wrong  close  the  connection". 
Another  basic  rule  is  to  have  few  options. 

POP2  does  not  parse  messages  in  any  way.  It  does  not  analyze  message 
headers  (Date:,  From:,  To:,  Cc:,  or  Subject:).  POP2  simply  transmits 
whole  messages  from  a  mailbox  server  to  a  client  workstation. 

The  Protocol 

The  POP2  protocol  is  a  sequence  of  commands  and  replies.  The  design 
draws  from  many  previous  protocols  of  the  ARPA- Internet  community. 

The  server  must  be  listening  for  a  connection.  Whcwi  a  connection 
is  opened  the  server  sends  a  greeting  message  and  waits  for 
ccmomands.  When  commands  are  received  the  server  acts  on  them  and 
responds  with  replies. 

The  client  opens  a  connection,  waits  for  the  greeting,  then  sends 
the  HELO  command  with  the  user  name  and  password  arguments  to 
establish  authorization  to  access  mailboxes.  The  server  returns 
the  number  of  messages  in  the  default  mailbox. 

The  client  may  read  the  default  mailbox  associated  with  the  user 
naiRe  or  may  select  another  mailbox  by  using  the  FOLD  command.  The 
server  returns  the  number  of  messages  in  the  mailbox  selected. 

The  cl  lent  begins  a  message  reading  transaction  with  a  READ 
commar.d.  The  read  comnand  may  qptlonally  Indicate  which  message 
number  to  read,  the  defauix:  is  the  current  message  (incremented 
when  a  message  is  read  and  set  to  one  when  a  new  folder  is 
selected)  .  The  server  returns  the  number  of  characters  in  the 
message. 
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The  client  asks  for  the  content  of  the  message  to  be  sent  with  the 
RETR  command.  The  server  sends  the  message  data. 

When  all  the  data  has  be*3n  received  the  client  sends  an 
acknowledgment  command.  This  is  one  of  ACKS,  ACKD,  and  NACK. 

ACKS  means  "I've  received  the  message  successfully  and  please 
keep  it  in  the  mailbox". 

ACKD  means  "I've  received  the  message  successfully  and  please 
delete  it  from  the  mailbox". 

NACK  means  "I  did  not  receive-  the  message  and  please  ke^  it  in 
the  mailbox". 

In  the  case  of  ACKS  or  ACKD  the  server  increments  the  current 
message  indicator.  In  the  case  of  NACK  the  current  message 
Indicator  stays  the  same. 

In  all  cases  tlie  server  returns  the  number  of  characters  in  the 
(now)  current  message . 

The  client  terminates  the  session  with  the  QUIT  command.  The 
server  returns  an  ok. 
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The  Normal  Scenario 


Client  Server 


Open  Connection  --> 

Wait  for  Connection 

< — 

+  POP2  Server  Ready 
^ait  for  Command 

HELO  Fred  Secret  --> 

<-- 

#13  messages  for  you 

Wait  for  Command 

READ  13  --> 

<-- 

=537  characters  in  that  message 

Wait  for  Command 

RETR  --> 

<-- 

(send  the  message  data) 

Wait  for  Command 

.^CKS  --> 

<-- 

=0  no  more  messages 

Wait  for  Command 

QUIT  --> 

<-- 

OK 

Close  connection  --> 

<-- 

Close  connection 

Wait  for  Connection  (go  back  to  start) 

Conventions 

Arguments 

These  arguments  have  system  specific  definitions, 
user  ’  A  login  account  name. 

password  -  The  password  for  the  login  account, 
mailbox  -  A  mailbox  name  (also  called  a  mail  folder)  . 
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Default  Mailboxes 
TOPS- 20 

MAIL. TXT. 1  -  from  login  directory 
UNIX 
both 

/usr /spoo 1/mai 1 /user 
and 

/usr/user /Mai 1 /inbox/ ♦ 

where  "user”  is  the  user  value  s^pplled  in  the  HELO  command. 
End  of  Line 

End  of  Line  is  Carriage  Return  (CR)  followed  by  Line  Feed  (LF) . 
This  sequence  is  indicated  by  "CRLF”  in  this  document.  This  end 
of  line  convention  must  be  used  for  commands  and  replies. 

Message  Length 

The  reply  to  the  READ  command  or  an  acknovledgnent  command  (AOCS, 
ACKD,  NAQC)  is  the  length  (a  character  count)  of  the  next  message 
to  be  transmitted.  This  includes  all  the  characters  in  the  data 
transmitted.  CBJLE  counts  as  two  characters.  A  length  of  zero 
means  the  message  does  not  exist  or  is  empty,  A  rcK^uest  to 
transmit  a  message  of  zero  length  will  result  in  the  server 
closing  the  connection.  The  message  is  transmitted  in  the 
standard  internet  format  described  in  RFC-822  [2]  and  NVT-ASCII. 
This  may  be  different  from  the  storage  format  and  may  make 
computing  the  message  length  from  the  stored  message  non- trivial . 

Message  Numbers 

The  reply  to  the  HELO  and  FOLD  commands  is  a  count  of  the  number 
of  messages  in  a  the  selected  mailbox.  The  READ  command  has  a 
message  number  as  an  optional  argument.  These  numbers  are 
decimal,  start  at  one,  and  cooputed  with  respect  to  the  current 
nailbox.  That  is,  the  first  message  in  a  mailbox  is  message 
number  1 . 

Numbers 

All  numbers  in  this  memo  and  protocol  are  decimal. 
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Quoting 

In  a  few  cases,  there  may  be  a  need  to  have  a  special  character  in 
an  argument  (user,  password,  or  mailbox)  that  is  not  allowed  by 
the  syntax  For  example,  a  space  in  a  password.  To  allow  for 
this,  a  quoting  convention  is  defined.  Unfortunately,  such 
quoting  conventions  "use  up"  another  otherwise  uninteresting 
character.  In  this  protocol  the  back  slash  "\"  is  used  as  the 
quote  character.  To  include  a  space  in  an  argument  the  two 
character  sequence  "back-slash,  space"  is  transmitted.  To  include 
a  back-slash  in  an  argument  the  two  character  sequence 
"back-slash,  back-sla^"  is  transmitted.  This  G[uoting  convention 
is  used  in  the  coranand  arguments  only,  it  is  not  used  in  the  mail 
data  transmitted  in  response  to  a  R£TR  command. 

Reply  Strings 

The  first  character  is  required  to  be  as  specificxi  (l.e., 

"r",  "=",  "#") .  The  optional  strings  that  follow  can  be 

whatever  the  inplementer  thinks  is  appropriate. 

Definitions  of  Commands  and  Replies 
Summary  of  Commands  and  Replies 


Commands  Relies 


HELO  user  password  ♦  OK 

FOLD  mailbox  -  Error 

READ  [n]  #xxx 

RETR  =yyy 

ACKS 

ACKD 

MACK 

QUIT 
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Commands 

HELO  user  password 

The  Hello  command  identifies  the  user  to  the  server  and  carries 
the  password  authenticating  this  user.  This  Information  is 
used  by  the  server  to  control  access  to  the  mailboxes.  The 
Hello  command  is  the  "HELO**  keyword,  followed  by  the  user 
argument,  followed  by  the  password  argument,  followed  by  CRLE. 

Possible  responses: 

"#nnn** 

where  nnn  is  the  number  of  messages  in  the  default 
mailbox,  ** 

**-  error  report**  and  Close  the  connection. 

FOLD  mailbox 

The  Folder  command  selects  another  mailbox  or  mail  folder.  The 
server  must  check  that  the  user  is  permitted  read  access  to 
this  mailbox.  If  the  mailbox  is  empty  or  does  not  exist,  the 
number  of  messages  reported  is  zero.  The  Folder  command  is  the 
**FOLD*'  keyword,  followed  by  the  mailbox  argument,  follo%ied  by 
CRLF. 

Possible  responses: 

**#nnn'* 

where  nrm  is  the  nuEober  of  messages  in  this  mailbox. 

READ  [nnn] 

The  Read  comaand  begins  a  messavTe  reading  transaction.  If  the 
Read  command  is  given  without  an  argument  the  current  message 
is  isplied  (the  current  message  indicator  is  incremented  by 
the  ACXS  or  ACKD  coamands)  .  I  f  an  argument  is  used  with  the 
Read  command  it  is  the  message  number  to  be  read,  jnd  this 
coonand  sets  the  current  message  indicator  to  that  value.  The 
server  returns  the  count  of  characters  in  the  message  to  be 
transmitted.  If  there  is  no  s»ssage  to  be  read,  the  count  of 
zero  is  returned.  If  the  message  was  previously  deleted  with 
the  ACXD  command,  the  count  of  zero  is  returned.  The  Read 
coenand  is  followed  by  the  RETR  coaaand,  the  READ  ccxnmand,  the 
FOLD  command,  or  the  QUIT  command.  Do  not  attempt  to  RETR  a 
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nkdssage  of  zero  characters.  The  Read  conixnancl  is  the  "READ" 
keyword,  optionally  followed  by  the  message  number  argument, 
followed  by  CRLF. 

Possible  re^^nses: 

— CCC 

where  ccc  is  the  number  of  characters  in  this  message. 

RETR 

The  Retrieve  command  confirms  that  the  client  is  ready  to 
receive  the  mail  data.  It  must  be  followed  by  an 
acknowledgment  command.  The  server  will  close  the  connection 
if  asked  to  transskit  a  message  of  zero  characters  (i.e., 
transmit  a  non-existent  message)  .  The  message  is  transmitted 
according  to  the  Internet  mail  format  standard  RFC-822  [2]  in 
NVT-ASCII.  The  Retrieve  command  is  the  "RETR"  keyword, 
followed  by  CRLF. 

Possible  responses: 
the  message  data 
Close  the  connection 

ACXS 

The  Acknowledge  and  Save  coomand  confirms  tliat  the  client  has 
received  and  accepted  the  message.  The  ACKS  cocasand  ends  the 
message  reading  transaction.  The  message  is  kept  in  the 
mailbox.  Ttm  current  message  indicator  is  incremented.  The 
server  returns  the  count  of  characters  in  the  now  current 
message  to  be  transmitted.  If  there  is  no  message  to  be  read 
or  the  message  is  marked  deleted,  the  count  of  zero  is 
returned.  The  Acknowledge  and  Save  command  is  tlie  "ACXS" 
keyword,  followed  by  CRLF. 

Porsible  responses: 

’•r:ccc" 

where  ccc  is  the  number  of  characters  in  the  next 
message. 
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ACKD 

Ihe  Acknowledge  and  Delete  command  confirms  that  the  client  has 
received  and  accepted  the  message.  The  ACKD  command  ends  the 
message  reading  transaction.  If  the  user  is  authorized  to  have 
write  access  to  the  mailbox,  the  mess?<ge  is  deleted  from  the 
mailbox.  Actually,  the  message  is  only  marked  for  deletion. 

The  actual  change  is  made  when  the  mailbox  is  released  at  the 
end  of  the  session  or  when  t'le  client  selects  another  mailbox 
with  the  FOLD  command.  The  messages  are  not  renumbered  until 
the  mailbox  is  released.  If  the  user  does  not  have  write 
access  to  the  mailbox  no  change  is  made  to  the  mailbox.  The 
response  is  the  same  whether  or  not  the  message  was  actually 
deleted.  The  current  message  Indicator  is  incremented.  The 
server  returns  the  count  of  characters  in  the  now  currait 
message  to  be  transmittei.  If  there  is  no  message  to  be  read 
or  the  message  is  marked  deleted,  the  count  of  zero  is 
returned.  The  Acknowledge  and  Delete  ccmand  is  the  "ACKD“ 
keyword,  followed  by  CRLF. 

Possible  responses: 

"=ccc‘* 

where  ccc  is  the  number  of  characters  in  the  next 

message. 

HACK 

The  negative  Acknowledge  coanana  reports  that  the  client  did 
not  receive  the  message.  The  HACK  ccrnsnarxl  ends  the  message 
reading  transaction.  The  message  is  k^t  in  the  mailbox.  The 
current  message  indicator  remains  the  same.  The  server  returns 
the  count  of  characters  in  the  current  message.  Since  the 
count  to  be  returned  is  for  the  message  just  transmitted  it  tho 
message  must  exist  and  not  be  marked  deleted,  and  the  count 
must  be  positive  (non-zero)  .  The  Negative  Acknowledge  command 
la  the  “HACK”  keyword,  followed  by  CRLF. 

Possible  responses: 

”=ccc” 

where  ccc  is  the  number  of  characters  in  this  message. 
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QUIT 

ITie  Quit  command  Indicates  the  client  is  done  with  the  session. 
The  server  sends  an  OK  response  and  then  closes  the  connection. 
The  Quit  command  is  the  "QUIT"  keyword,  followed  by  CRLF. 

Possible  responses: 

"+  OK"  and  Close  the  connection 


Replies 

Greeting 

The  greeting  is  sent  by  the  server  ts  soon  as  the  connection  is 
established.  The  greeting  is  a  plus  sign,  followed  by  the 
protocol  name  ("POP2") ,  followed  by  the  server  host  name, 
optionally  followed  by  text,  and  ending  with  a  CRLF. 


The  success  or  plus  sign  response  indicates  successful 
conpletion  of  the  operation  specified  in  the  command.  The 
success  response  is  a  plus  sign,  optionally  followed  by  text, 
and  ending  with  a  CRLF. 


The  failure  or  minus  sign  response  indicates  the  failure  of  the 
operation  specified  in  the  command.  The  failure  response  is  a 
minus  sign,  optionally  followed  by  text,  and  ending  with  a 
CRLF. 


The  length  or  equal  sign  response  tells  the  length  in 
characters  of  the  message  referenced  by  the  command.  The 
length  response  is  a  equal  sign,  followed  by  a  number, 
optionax.’  followed  by  text,  and  endbig  with  a  CRLF. 

# 

The  count  or  number  sign  response  tells  the  number  of  messages 
in  a  folder  or  mailbox  referenced  by  the  command.  The  count 
response  is  a  number  sign,  followed  by  a  number,  optionally 
followed  by  text,  and  ending  with  a  CRLF. 
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Timeouts 

In  any  protocol  of  this  type  there  have  to  be  timeouts.  Neither 
side  wants  to  get  stuck  waiting  forever  for  the  other  side 
(particularly  Is  the  other  side  has  gone  crazy  or  crashed)  . 

The  client  e^qpects  a  reply  to  a  conmand  fairly  qul':kly  and  so 
should  have  a  short  timeout  for  this.  This  timeout  Is  called  Tl. 

For  some  servers «  It  may  take  some  processing  to  compute  the 
number  of  messages  In  a  mailbox,  or  the  length  of  a  message,  or 
to  reformat  a  stored  message  for  transmission,  so  this  time  out 
has  to  allow  for  such  processing  time.  Also  care  must  be  taken 
not  to  timeout  waiting  for  the  Conpletlon  of  a  RETR  rspl'/  while 
a  long  message  Is  In  fact  being  transfered. 

The  server  Bxpocts  the  session  to  progress  with  some  but  not 
excessive  delay  between  commands  and  so  should  have  a  long  timeout 
waiting  for  the  next  command.  This  time  out  Is  T2. 

One  model  of  use  of  this  protocol  Is  that  any  number  of 
different  types  of  clients  can  be  built  with  different  ways  of 
interacting  with  the  human  user  and  the  server,  but  still 
esgjectlng  the  client  to  open  the  connection  to  the  server, 
present  a  sequence  of  commands,  and  close  the  connection, 
without  waiting  for  Intervention  by  the  human  user.  With  such 
client  Implementations,  It  Is  reasonable  for  the  server  to  have 
a  fairly  small  value  for  timeout  T2. 

On  the  other  hand,  one  could  easily  have  the  client  be  very 
human  user  directed  with  the  user  making  decisions  between 
commands.  This  would  cause  arbitrary  delays  between  client 
commands  to  the  server,  and  require  the  value  of  timeout  T2  to 
be  quite  large. 

Implementation  Discussion 

Conssents  on  a  Server  on  TOPS -20 

On  TOPS- 20,  a  mailbox  Is  a  single  file.  New  messages  are  appended 
to  the  file.  There  Is  a  separator  line  between  messages. 

The  tricky  part  of  Implementing  a  POP2  server  on  TOPS- 20  Is  to 
provide  for  deleting  messages.  This  only  has  to  be  done  for  the 
mailboxes  (files)  for  which  the  user  has  write  access.  The 
problem  Is  to  avoid  both  (1)  preventing  other  users  from  a  ;cessing 
or  updating  the  mailbox  for  long  periods,  and  (2)  accidentally 
deleting  a  message  the  user  has  not  seen. 
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One  suggestion  is  as  follows: 

When  a  mailbox  is  first  selected,  if  the  user  has  write  access, 
rename  the  mailbox  file  to  some  teoporary  name.  Thus  new 
messages  will  be  placed  in  a  new  instance  of  the  mailbox  file. 
Conduct  all  POP2  operation  on  the  tenporary  mailbox  file 
(including  deleting  messages)  .  When  the  POP2  session  is  over 
or  another  mailbox  is  selected,  prepend  any  messages  left 
undeleted  in  the  tenporary  file  to  thcj  new  instance  of  the 
mailbox  file. 


Sizes 

The  maximum  length  of  a  command  line  is  512  characters  (including 
the  command  word  and  the  CRLF)  . 

The  maximum  length  of  a  reply  line  is  512  characters  (including 
the  success  indicator  (+,  -,  =,  #)  and  the  CSLF)  . 

The  maximum  length  of  a  text  line  is  1000  characters  (including 
CRLF) . 

ISI  has  developed  a  POP2  server  for  TX)PS-20  and  for  Berkeley  4.2 
Unix,  and  a  POP2  client  for  an  IBM-PC  and  for  Berkeley  4.2  Unix. 

Extensions  Not  Supported 

POP2  does  not  examine  the  internal  data  of  messages.  In  particular, 
the  server  does  not  parse  message  headers. 

The  server  doesn't  have  any  state  Information  (i.e.,  it  doesn't  know 
from  one  session  to  the  next  what  has  happened)  .  For  exanple,  the 
server  doesn't  know  which  messages  were  received  since  the  last  time 
the  user  used  POP2,  so  it  can't  send  Just  the  "new"  messages. 
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Exaioples 

Example  1: 

Client 


Open  connection  — > 

HELO  POSTEL  SECRET  --> 

<  — 

READ 

RETR  --> 

ACKD 

RETR 

<  •“ 

ACKD 

QUIT 

Close  connection  -->  <-- 


Server 

Wait  for  connection 

+  POP2  USC-ISIF.ARPA  Server 

#2  messages  in  your  mailbox 

=537  characters  in  message  1 

[data  of  message  1] 

=234  characters  in  message  2 

[data  of  message  2] 

=0  no  more  messages 

+  OK,  bye,  bye 
Close  connection 
Go  back  to  start 
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Exanple  2: 


Client 


Server 


Walt  for  connection 

Open  connection 

+  POP2  ISI-VAXA.ARPA  server  here 

HELO  smith  secret  --> 

< —  #35  messages 

FOLD  /usr/spool/mall/smlth  --> 

<"■  #27  messages 

READ  27  --> 

< —  =10123  characters  In  that  message 

REIR  --> 

[data  of  message  27] 

ACKS  --> 

<->  =0  no  more  messages 

QUIT  --> 

♦  bye,  call  again  sometime. 

Close  connection  <--  Close  connection 

Go  back  to  start 


Exiiople  3: 


Client 


Open  connection 
HELO  Jones  secret  --> 


Server 


Walt  for  connection 


<--  ♦  POP2  ISI-VAXA..ARPA  server  here 


READ 


#0  messages 
<--  Close  connection 


Close  connection  --> 


Go  back  to  start 
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Formal  Syntax 


<cliglt> 


2  I  3  I  4  I  5  I  6 


8  I  9 


< letter > 


A  I  B  I  C  I  ...  I  Z 
a  I  b  I  c  I  ...  I  2 


<punct> 


!  I  ■*  I  #  I  M  %  I  6  I  •  I  (  I  )  I  *  I 

C  I  ]  I  *  I  -  I  '  I  {  I  I  I  >  I  - 


<qaote> 


<any> 


=  any  one  of  the  128  ASCII  codes 


=  cai  rlage  return^  code  10 


line  feed«  code  13 


=  ^pace«  code  32 


<C31LF> 


-  <CR>  <LF> 


<prlnt>  =  <  letter >  |  <dlglt>  |  <punct>  |  <quote>  <any> 


<char> 


=  <prlnt>  I  <SP> 


<word> 


<prlnt>  I  <prlnt>  <word> 


<atrlng>  =  <char>  |  <char>  <string> 


=  < letter >  |  <dlglt> 


<ldh> 


=  <lettor>  I  <dlgit> 


<ldhs> 


=  <ldh>  (  <ldh>  <ldhs> 


<naiDe> 


=  <  letter >  [  [  <l<lhs>  ]  <ld>  ] 


<host> 


=  <name>  |  <namc>  .  <ho5t> 


<user> 


=  <word> 


<password>  =  <word> 


<mallbox>  =  <strlng> 


<nunber>  =  <diglt>  |  <digit>  <nuznber> 
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<helo>  -  HELO  <SP>  <user>  <SP>  <password>  <CRLF> 

<fold>  =  FOLD  <SP>  <mailbox>  <CRLF> 

<read>  =  READ  [<SP>  <number>]  <CRLF> 

<retr>  =  REIR  <CRLF> 

<acks>  =  ACKS  <CRLF> 

<ackd>  =  ACKD  <CRLF> 

<naci^>  =  HACK  <CRLF> 

<qult>  =  QUIT  <CRLF> 

<ok>  =  +  [<SP>  <string>]  <CRLF> 

<err>  =  -  [<SP>  <strlng>]  <CRLF> 

<count>  =  #  <number>  [<SP>  <string>]  <CRLF> 

<groet>  =  ♦  <SP>  POP2  <SP>  <host>  [<SP>  <string>]  <CRLF> 

<length>  =  «  <number>  [<SP>  <string>]  <CRLF> 

<coiiii>jff>d>  =  <h©lo>  I  <fold>  I  <read>  |  <retr>  | 

<acks>  I  <ackd>  |  <nack>  j  <quit> 

<r«ply>  =  <ok>  I  <err>  |  <count>  |  <length>  |  <gr©et> 
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Client  State  Diagram 


I 

I 

V 

4 - 4 

I  CALL  |--- 


+  BYE 


Greet  j  Close 


+--- - + 

->|  EXIT  I 


Greet 

HELO 


»  I 

#NNN  *  I  I 

— I  V  V 

FOLD  I  + . + 

♦<---{  NMHR  I* 

■f - -► 


1 

1 

1  #NNN 

=CCC 

1 

1 

1 

i  READ 

1 

FOLD 

1 

1 

1 

1 

=CCC 

1 

V 

---- 

=ccc 

♦ - >♦ - 

QUIT 

---- 

1  SIZE 

t 

READ 

4< - 

•  ♦ - 

1 

1 

j  =CCC 

data 

1 

j  -  -  -  - 

---- 

1 

1  RETR 

ack 

1 

1 

I  XFER  I 
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Server  State  Diagram 


Listen 


LSTN  I 


•+  Close 


i  Close 


I  DONE  I 

-f - + 


j  Open 


Greet 


I  AlfTH  I 


FOLD  - -*• 

-  -  I  mbox  |- 

#NNN  ♦<---♦ . ♦ 


BYE 


QUIT 
♦  BYE 


QUIT 


READ  ♦ - >♦ - ♦ 

-  I  ITEM  I* 

5=CCC  ♦< - ♦ - ♦ 
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Combined  Flow  Diagi'am 


|CALL|<- 

|LSTN| 

I  Greet 


I  ^ . 

I  -  QUIT 
V  I 

|CALL|  HELO 
lAJUIHl . 


|NMFR| 

4'  ---4 

I  #NNN 


- >4 

I 

V 

4----4 

I  EXIT  I 
lAUIHj 

4----4 

♦  Bye 


I 


QUIT 


4-' 

FOLD  - 

—  I 


I 

V 

.->4 - 

imORI  READ 
|MBOX| . 

- 4 - 4 


I 


4----4 

|SIZ£| 

->|MBOX| 

4 - 4 

I  =ccc 

I 


- >4 

I 

V 

I  EXIT  I 
|MBOX| 

4-  ---4 

♦  Bye  I 


FOLD  ♦<-- 

. ■*  1  ♦ - 

->4  1 

---- 

-  1  -  QUIT 

1  1 

#NNN 

1  V  1 

V  1 

4 - >4 - 4 

4----4 

4----4  j 

READ 

ISIZE  1  RETR 

IXFERI 

lEXITI  1 

---- 

1  1  ITEMj . 

>|ITEM| 

IITEMI  1 

=ccc 

4< - 4 - ♦ 

4-  *  -  -4 

4 - 4  j 

1  data 

1 

1  1 

1  1 

1 

=CCC  1 

1 

V  4 

1  1 
Bye  1  1 

4-  -  -  -4 

1  1 

|SIZE|  Ack 

IXFERI 

i  i 

|NEXT|< . 

-INExri 

1  1 

♦----4 

♦  ----4 

1  1 

1  1 

1  i 

V  V 

Butler,  et.  al . 


^ - ^ 

I  EXIT  !-''>♦ 

I  done  I 


[Page  191 


3*935 


DDN  PROTOCOL  HANDBOOK  -  VOLUME  THREE 


RFC  937 

Post  Office  Protocol 

«^a.ient  Decision  Table 


STATE 

NMBR  I  SIZE 


INPUT  I  CALL 


XFER 


EXIT 


Greet  |  2 

- + - 

#NNN  I  1 


1 

3 


I  1 
I  1 


1 

1 


6 

6 


=CCC  I  1 

- - -f - 

date  I  1 


1 

1 


I  4 
I  1 


1 

5 


6 

6 


♦  Bye  1  1 

Close  I  1 


1 

1 


I 

i  1 


1 

1 


6 

6 


other  I  1 

- -f - 

Timeout |  1 

- -f---- 


1 

1 


I  _1 
I  1 


X 

1 


6 

6 
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Actions: 


1.  this  is  garbage.  Send  '*QU1T**,  and  go  to  EXIT  state. 

2.  (a)  If  the  greeting  is  ri^t  then  send  ’HELO” 

and  go  to  MMBR  state^ 

(b)  Else  send  “QUIT*  and  go  to  EXIT  state. 

3.  (a)  If  user  wants  this  folder  and  KNN  >  0 

then  send  "READ"  and  go  to  SIZE  state, 

(b)  If  user  %rants  a  this  folder  and  NNN  -  0 
then  send  "QUir*  and  go  to  EXIT  state, 

(c)  If  user  wants  «  different  folder 
then  send  "FOLD"  and  go  to  NMBR  state. 

4.  (a)  If  user  %fants  this  message  and  CCC  >  0 

then  send  **RETR"  and  go  to  XFER  state, 

(b)  If  user  wants  a  this  message  and  CCC  »  0 
then  send  "QUIT"  and  go  to  EXIT  state, 

(c)  If  user  wants  a  different  message 
then  send  **READ"  and  go  to  SIZE  state. 

5.  (a)  If  user  wants  this  message  k^t 

than  send  "AdCS"  and  go  to  SIZE  state, 

(b)  If  user  wants  a  this  message  deleted 
then  send  "ACKD"  and  go  to  SIZE  state, 

(c)  If  user  wants  a  this  message  again 
then  send  "NACK"  and  go  to  SIZE  state. 

6.  Close  the  conraection. 
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Server  Decision  Table 


1  STATE 

INPUT 

1 

LSIN 

j  AUTH 

1  MBOX 

ITEM 

1  NEXT 

1  DONE 

Open 

1 

2 

1  ^ 

1  1 

1 

1  1 

j  1 

HELO 

1 

1 

1  ^ 

1  1 

1 

j  1 

1  1 

FOLD 

1 

1 

1  1 

1  5 

5 

1  1 

1  1 

READ 

1 

1 

1  1 

1  6 

6 

1  1 

1  1 

RETR 

i 

1 

1  1 

1  1 

7 

{  1 

1  1 

ACKS 

1 

1 

1  1 

1  1 

1 

i  8 

1  1 

ACKD 

1 

1 

1  1 

1  1 

1 

1  B 

1  1 

HACK 

i 

1 

1  1 

1  1 

3 

1  8 

1  1 

QUIT 

—  +  * 

1 

1 

1  4 

1  4 

4 

1  1 

1  1 

Close 

•  +  ■ 

1 

1 

1  1 

1  1 

1 

1  ^ 

1  9 

other 

1 

1 

1  1 

1 

1 

1  1 

j  1 

Timeout j 

1  1 

1  1 

1 

1  ^ 

1  1 
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Actions : 

1.  Iliis  is  garbage.  Send  error",  and  Close  the  connection. 

2.  Send  the  greeting.  Go  to  AUTH  state. 

3.  (a)  If  authorized  user  then  send  "#NNN"  and  go  tp  MBOX  state, 
(b)  Else  send  error"  and  Close  the  connection. 

4.  Send  "+  Bye"  and  go  to  DONE  state. 

5.  Send  "+NNN"  and  go  to  MBOX  state. 

6.  Send  "=CCC"  and  go  to  ITEM  state. 

7.  If  message  exists  then  send  the  data  and  got  to  NEXT  state. 
Else  Close  the  connection. 

8.  Do  what  ACKS/ACKD/NACK  require  and  go  to  ITEM  state. 

9.  Close  the  corinoction. 
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